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The  Engineous  Software  STTR  Team,  including  team  members  from  Northrop  Grumman,  Naval 
Undersea  Warfare  Center  (NUWC),  Massachusetts  Institute  of  Technology  (MIT),  and  Elon  University; 
proposed  at  the  outset  of  the  project  that  it  could  develop  an  integrated  Multi-disciplinary  Optimization 
(MDO)  system  of  naval  ship  design  and  mission  effectiveness.  Specifically,  the  team  intended  to  use  a  ship 
model  of  interest  to  the  Navy  in  an  effort  to  demonstrate  that  disparate  ship  analysis  tools  could  be 
integrated  under  a  single  framework  and  automated.  This  integrated,  automated  system  would  allow  its 
users  to  measure  ship  performance  and  effectiveness,  as  well  as  accounting  for  uncertainty  in  those 
measurements,  through  design  exploration  techniques,  such  as  optimization,  design  of  experiments  (DOE), 
and  quality  engineering  analysis  (e.g.  Monte  Carlo  analysis).  The  primary  struggle  on  the  project  was 
acquiring  analysis  models  to  use  in  the  MDO  system.  The  time  required  to  obtain  the  models, 
unfortunately,  limited  the  amount  of  analysis  the  team  was  able  to  perform.  However,  once  the  models 
were  obtained,  the  team  was  able  to  quickly  integrate  them  and  show  the  power  and  flexibility  of  the  MDO 
system.  The  results  showed  that  the  system  was  able  to  quickly  apply  numerous  exploration  techniques, 
including  the  Multi-Objective  Genetic  Algorithm  specifically  developed  for  the  STTR,  to  the  integrated 
models.  Hundreds  of  ship  designs  were  evaluated  in  the  pursuit  of  an  optimum  design;  while  taking  into 
account  uncertainty.  A  measured  improvement  of  6%  in  lifecycle  cost  was  calculated  for  an  optimization 
analysis.  It  was  also  found  that  while  introducing  uncertainty  in  the  analysis  that  the  lifecycle  cost  was 
perturbed  by  only  a  maximum  variation  of  1%.  While  these  results  are  only  first  order  analyses  used  to 
demonstrate  the  feasibility  of  developing  such  a  system,  they  offer  a  compelling  case  for  further 
exploration.  The  next  phase  of  this  project  could  bring  enormous  advances  in  the  MDO  ship  system.  By 
developing  more  robust  models,  tightly  integrating  the  design  integration  components,  including  new 
analysis  tools,  and  possibly  pushing  the  integration  capabilities  across  the  internet  to  include 
geographically  disperse  design  centers  the  system  could  move  from  the  compelling  demonstration  to  a 
user-friendly  MDO  naval  design  framework. 
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1.0  Abstract 

The  Engineous  Software  STTR  Team,  including  team  members  from  Northrop 
Grumman,  Naval  Undersea  Warfare  Center  (NUWC),  Massachusetts  Institute  of 
Technology  (MIT),  and  Elon  University;  proposed  at  the  outset  of  the  project  that  it 
could  develop  an  integrated  Multi-disciplinary  Optimization  (MDO)  system  of  naval 
ship  design  and  mission  effectiveness.  Specifically,  the  team  intended  to  use  a  ship 
model  of  interest  to  the  Navy  in  an  effort  to  demonstrate  that  disparate  ship  analysis  tools 
could  be  integrated  under  a  single  framework  and  automated.  This  integrated,  automated 
system  would  allow  its  users  to  measure  ship  performance  and  effectiveness,  as  well  as 
accounting  for  uncertainty  in  those  measurements,  through  design  exploration 
techniques,  such  as  optimization,  design  of  experiments  (DOE),  and  quality  engineering 
analysis  (e.g.  Monte  Carlo  analysis). 

The  primary  struggle  on  the  project  was  acquiring  analysis  models  to  use  in  the  MDO 
system.  The  time  required  to  obtain  the  models,  unfortunately,  limited  the  amount  of 
analysis  the  team  was  able  to  perform.  However,  once  the  models  were  obtained,  the 
team  was  able  to  quickly  integrate  them  and  show  the  power  and  flexibility  of  the  MDO 
system. 

The  results  showed  that  the  system  was  able  to  quickly  apply  numerous  exploration 
techniques,  including  the  Multi-Objective  Genetic  Algorithm  specifically  developed  for 
the  STTR,  to  the  integrated  models.  Hundreds  of  ship  designs  were  evaluated  in  the 
pursuit  of  an  optimum  design;  while  taking  into  account  uncertainty.  A  measured 
improvement  of  6%  in  lifecycle  cost  was  calculated  for  an  optimization  analysis.  It  was 
also  found  that  while  introducing  uncertainty  in  the  analysis  that  the  lifecycle  cost  was 
perturbed  by  only  a  maximum  variation  of  1%.  While  these  results  are  only  first  order 
analyses  used  to  demonstrate  the  feasibility  of  developing  such  a  system,  they  offer  a 
compelling  case  for  further  exploration. 

The  next  phase  of  this  project  could  bring  enormous  advances  in  the  MDO  ship  system. 
By  developing  more  robust  models,  tightly  integrating  the  design  integration 
components,  including  new  analysis  tools,  and  possibly  pushing  the  integration 
capabilities  across  the  internet  to  include  geographically  disperse  design  centers  the 
system  could  move  from  the  compelling  demonstration  to  a  user-friendly  MDO  naval 
design  framework. 

2.0  Objectives 

The  objectives  of  Phase  I  outlined  in  the  proposal  addressed  the  following  questions: 

1 .  What  codes  are  currently  in  use  at  naval  ship  design  organizations?  How  are  these 
codes  used,  and  how  do  they  interact  with  each  other? 

2.  What  codes  are  currently  in  use  to  evaluate  mission  effectiveness?  How  are  these 
codes  used?  How  do  they  interact  with  other  mission  analysis  codes  or  ship  design 
codes? 


3.  What  is  the  feasibility  of  integrating  the  ship  design  analysis  and  mission 
effeetiveness  codes  into  a  single  design  framework  such  as  the  Engineous 
Collaborative  environment  called  PIPER? 

4.  How  can  integrated  ship  design/synthesis  and  mission  effectiveness  codes  be  applied 
to  other  organizations  within  the  Center  for  Innovative  Ship  Design  at  NSWC-CD, 
the  Navy,  industry  and  universities? 

5.  What  is  the  feasibility  of  integrating  a  pareto  multidisciplinary  optimization  technique 
into  a  collaborative  engineering  environment  (such  as  PIPER)  including: 

■  Parallel  processing 

■  Distributed  Processing 

■  Multiple  operating  systems 

6.  What  are  the  costs  and  benefits  of  accounting  for  uncertainties  in  data  inputs  for  ship 
design? 

7.  Demonstrate  the  feasibility  of  integrating  at  least  one  ship  design  code  and  one 
mission  effectiveness  code  to  assess  a  design  currently  being  evaluated  by  the  Center 
for  Innovative  Ship  Design  at  NSWC-CD. 

8.  Generate  a  work  plan  for  a  Phase  II  proposal. 


3.0  Team  Members 

The  STTR  team  members  included  industry  participants  from  Northrop  Grumman  Ship 
Systems  in  Pascagoula,  Mississippi  and  the  Naval  Undersea  Warfare  Center  in  Newport, 
Rhode  Island;  Director  of  the  Sea  Grant  College  Program  from  MIT;  a  Multi- 
Disciplinary  Optimization  (MDO)  consultant  from  Elon  University;  and  participants 
from  Engineous  Software.  A  full  list  of  team  members  is  included  in  Appendix  B  of  this 
document. 

4.0  Analysis  Tools 

Based  on  recommendations  from  the  team  members,  the  following  candidates  for 
analysis  tools  were  chosen: 

1 .  ASSET  -  Ship  design  (e.g.  dimensions,  weight,  etc.) 

2.  SMP  -  Seakeeping 

3.  MIT  Cost  model 

4.  SIMSmart  -  Piping/HVAC  layout 

5.  Signatures  -  Stealth 

The  team  soon  realized  that  SIMsmart  would  provide  too  much  detail  design  as  compared 
to  the  other  analysis  tools.  While  optimization  at  the  detailed  design  stage  of  ship  design 
was  still  desirable,  using  SIMsmart  was  not  inline  with  the  team’s  proposal,  which  was  to 
focus  on  the  80%  of  ship  building  costs  locked  in  at  conceptual  design  phase.  Work  on 
SIMsmart  ceased  in  November. 


Due  to  its  classified  status,  Signatures  was  also  removed  from  the  team’s  tool  list.  It  was 
determined  that  no  unclassified  analysis  tool  existed  to  effectively  measure  stealth 
capabilities  of  ships. 

Thus,  ASSET,  SMP,  and  the  MIT  Cost  model  were  used  in  the  integrated  analysis.  Using 
these  tools,  the  team  would  develop  a  generalized  prototype  solution  to  demonstrate  the 
integrated  MDO  system. 

5.0  Analysis  Models 

After  identifying  the  analysis  tools  for  our  system,  the  team  set  out  to  find  models  for 
each  analysis  tool.  However,  identifying  proper  ship  models  to  use  in  our  MDO  analysis 
was  a  source  of  struggle  on  the  project. 

As  leaders  in  ship  design,  the  members  from  Northrop  Grumman  oversaw  the  task  of 
acquiring  ship  models  for  ASSET  and  SMP.  The  MIT  cost  model  could  be  altered  to  suit 
any  ship  model  relatively  quickly,  so  no  specific  model  was  needed.  At  the  beginning  of 
the  project,  Northrop  Grumman  identified  the  ECS  ship  class  as  a  good  candidate  for  the 
integrated  analysis.  Unfortunately,  it  was  later  determined  that  the  LCS  models  for  SMP 
and  ASSET  would  not  be  available,  since  Northrop  Grumman  was  entering  an 
unsolicited  bid  to  the  Navy  on  that  project.  At  that  point  Northrop  suggested  using  the 
Multipurpose  Force  Future  (MPFF)  model  as  a  replacement  (See  Appendix  C  for  details 
on  the  MPFF  ship  presented  during  our  ONR  briefing  in  November).  Northrop  was  using 
a  baseline  of  three  classes  of  ships  -  LPD  17,  LHD8,  and  LMSR  -  to  develop  the  MPFF 
ship  class.  After  unsuccessfully  trying  to  acquire  MPFF  specific  models,  in  late 
December  Northrop  suggested  we  use  the  LHD8  ship  class  as  our  baseline  for  the  project 
as  it  would  be  a  good  starting  point  to  the  MPFF  analysis. 

ASSET  included  an  LHD8  model  within  the  databanks  provided  with  its  software,  so 
only  an  SMP  model  was  needed.  It  was  determined  that  this  model  would  be  developed 
with  the  help  of  NUWC  and  MIT.  By  mid- January,  the  team  had  LHD8  models  for 
ASSET,  SMP,  and  the  MIT  cost  models;  and  was  ready  to  explore  the  ship  design  space. 

6.0  Integration 

Engineous  Software’s  FIPER  product  was  used  as  the  system  integration  framework  and 
for  the  design  exploration  analysis.  [For  a  full  background  on  FIPER  and  its  history, 
please  refer  to  Appendix  D  in  this  report.]  By  leveraging  FIPER’ s  ability  to  rapidly 
integrate  disparate  analysis  tools,  ASSET,  SMP,  and  the  MIT  cost  model  could  be  tied 
together  in  a  flexible  and  easily  changeable  way.  FIPER  provided  not  only  that 
integration  framework,  but  also  techniques  in  design  of  experiments  (DOE), 
optimization,  and  quality  engineering.  Thus,  FIPER  supplied  a  complete  architecture  for 
a  MDO  system  for  naval  ship  design  and  mission  effectiveness. 

Bringing  together  the  ASSET,  SMP,  and  cost  model  tools  required  using  two  types  of 
FIPER  integration  components:  the  Microsoft/Excel  FIPER  component  used  for 
communicating  directly  with  an  Excel  spreadsheet,  and  the  Data  Exchange  component 


used  to  communicate  with  any  program  that  can  accept  and  return  input  and  results  as 
text  files.  The  MIT  cost  model  and  ASSET  were  integrated  using  the  Excel  component; 
SMP  using  the  Data  Exchange  component. 

The  MIT  cost  model  component  was  a  relatively  straight  forward  integration  using  the 
Excel  component.  The  component  provides  an  editor  that  permits  the  user  to  select 
particular  spreadsheet  cells  directly  and  give  those  cells  parameter  names.  These 
parameters  are  how  PIPER  transfers  information  in  and  out  of  the  spreadsheet.  A  picture 
of  this  editor  is  shown  in  Figure  I. 


Figure  1  -  FIPER  Editor  for  MIT  Cost  Spreadsheet 

Once  the  user  has  “mapped”  all  the  input/output  parameters  of  interest  that  he/she  wishes 
to  write/read  to  or  from  the  spreadsheet,  FIPER  provides  these  parameters  as 
input/outputs  for  the  other  integrated  analysis  tools  (i.e.  ASSET  and  SMP).  Figure  2 
shows  the  list  of  parameters  that  were  input  for  the  cost  model  and  the  resulting  output 
generated  by  the  spreadsheet. 


Figure  2  -  Parameters  for  the  MIT  Cost  Spreadsheet 

The  complete  cost  spreadsheet  with  full  parameter  descriptions  can  be  seen  in 
Appendix  E. 


The  ASSET  model  used  a  similar  integration  scheme  as  the  MIT  model  cost  spreadsheet. 
One  feature  of  ASSET  is  that  editing  parameters  and  retrieving  results  can  be  done 
through  an  Excel  spreadsheet.  Using  a  spreadsheet  allows  the  user  to  identify  key 
parameters  and  display  them  in  a  “dashboard”  like  manner  instead  of  searching  through 
an  expansive  graphical  user  interface.  A  spreadsheet  was  set  up  to  communicate  with 
ASSET.  Figures  3-5  show  those  input  and  output  parameters  as  they  appear  in  the 
spreadsheet. 
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Figure  3  -  ASSET  Inputs 


Figure  4  -  ASSET  Outputs 


Figure  5  -  ASSET  Hull  Forms 


Once  parameters  were  set  up  in  the  spreadsheet,  a  set  of  Excel  macros  were  executed  to 
handle  the  transfer  of  data  between  Excel  and  ASSET.  These  macros  were  defined  in  an 
example  Excel  spreadsheet  provided  with  the  installation  of  ASSET,  and  were  slightly 
altered  to  fit  this  particular  problem. 


Since  Excel  was  used  as  a  front-end  data  entry  tool,  the  FIPER  Excel  component  was 
once  again  used  for  integration.  Figure  6  shows  the  ASSET  integration  editor. 
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Figure  6  -  FIPER  Editor  for  ASSET-Excel  Interface 


Just  like  the  MIT  cost  spreadsheet,  the  input  and  output  parameters  were  communicated 
ffom/to  FIPER,  allowing  those  values  to  be  shared  with  other  integrated  analysis  tools. 
Figure  7  shows  a  list  of  those  parameters. 


Figure  7  -  ASSET  parameters 


SMP  used  piper’s  Data  Exchange  component  to  communicate  input  and  output 
parameter  values.  This  component  is  FIPER’s  most  generic  integration  capability, 
allowing  users  to  integrate  any  tool  that  provides  model  input/output  via  ASCII  text  fdes. 
Since  SMP  does  use  ASCII  input  models  and  ACSII  results  fdes,  the  Data  Exchange 
component  was  the  natural  choice  for  integration  into  PIPER.  The  Data  Exchange 
component  editor  was  used  to  identify  the  input  and  output  parameters  of  interest, 
allowing  the  user  to  highlight  those  parameters  from  SMP’s  input  and  output  text  fdes. 
Figures  8-10  show  examples  of  this  ability  to  highlight  values  in  order  to  identify  them  as 
parameters  to  PIPER. 
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Figure  8  -  SMP  input  fde  with  parameters  highlighted 


Figure  9  -  SMP  Irregular  Wave  input  file  with  a  parameter  highlighted 


Figure  10  -  SMP  output  file  with  parameters  highlighted 


As  can  be  seen,  the  identification  of  parameters  is  done  by  simply  highlighting  the 
pertinent  input/output  values.  The  user  is  actually  assigning  a  parameter  name  to  the 
selected  value  of  interest.  Once  FIPER  starts  iterating  on  different  ship  designs,  these 
highlighted  parameters  have  the  current  values  substituted  for  the  analysis. 

Figure  1 1  and  12  show  the  parameters  associated  with  the  SMP  model.  As  with  the  cost 
model  and  ASSET,  these  parameters  are  available  to  the  other  tools.  This  permits  the 
mapping  of  same  parameters  between  two  different  tools.  For  example,  weight  comes  out 
of  ASSET  and  gets  mapped  into  the  cost  model  spreadsheet. 


Figure  1 1  -  SMP  parameters  (first  half) 


Figure  12  -  SMP  parameters  (second  half) 


Besides  the  integration  of  ASSET,  SMP,  and  the  MIT  eost  model,  two  additional 
eomponents  were  needed  to  eomplete  the  integrated  analysis  system.  Two  ealculation 
blocks  were  developed  to  help  with  minor  calculations.  The  first  was  used  to  convert 
parameters  that  were  metric  in  the  ASSET  model,  but  in  English  units  in  the  cost  model. 
The  calculation  component  is  nothing  more  than  a  scientific  calculator  that  can  operate 
on  PIPER  parameters.  Figure  13  shows  the  calculations  done  between  ASSET  and  the 
cost  model. 


Figure  13  -  Unit  Conversion  between  ASSET  and  the  cost  model 

The  second  calculation  component  was  used  to  calculate  maximum  vertical  displacement 
and  velocity  by  examining  several  key  points  on  the  ship.  The  maximums  were  checked 
against  constraints  to  insure  that  the  ship  design  being  evaluated  was  feasible.  Figure  14 
shows  the  calculations  done. 


Figure  14  -  Calculation  for  Maximum  Vertical  Displacement  and  Velocity 

Finally,  the  overall  integration  of  ASSET,  SMP,  the  cost  model,  the  unit  conversion 
calculation,  and  the  maximum  displacement  and  velocity  calculation  is  shown  in 
Figure  15. 


Figure  15  -  Overall  System  Integration 

The  general  flow  of  the  system  is  as  follows:  the  user  provides  input  for  ASSET;  ASSET 
calculates  the  ship  dimensions  and  weight  and  provides  output,  which  is  converted  using 
the  unit  conversion  calculation  component;  the  ASSET  output  is  also  sent  to  SMP;  the 
converted  parameters  from  the  calculation  component  are  passed  to  the  cost  model;  SMP 
calculates  the  seakeeping  and  passes  the  output  to  the  second  calculation  component;  the 
second  calculation  component  determines  the  max  displacement  and  velocity,  which  are 
measured  against  constraints.  Figure  16-20  shows  the  mapping  of  parameters  between 
the  different  analysis  tools. 
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Figure  16  -  Parameter  Mapping  between  ASSET  and  the  Unit  Conversion  Calculation 


Figure  17  -  Parameter  Mapping  between  ASSET  and  SMP 
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Figure  18  -  Parameter  Mapping  between  Unit  Conversion  Calculation  and  the  Cost 

Model 
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Figure  19  -  Parameter  Mapping  between  SMP  and  Maximum  Veloeity  and 
Displacement  Calculation  (First  Half) 
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Figure  20  -  Parameter  Mapping  between  SMP  and  Maximum  Veloeity  and 
Displacement  Calculation  (Second  Half) 


The  integration  was  broken  into  two  parts:  one  model  that  focused  on  variations  in 
length  without  accounting  for  variations  in  the  beam;  and  a  second  model  that  accounted 
for  variation  in  beam  with  variations  in  length.  The  former  was  done  as  a  first  step  to 
prove  the  concept  of  a  functioning  MDO  ship  system.  The  later  was  a  more  realistic 
evaluation  system  that  accounted  for  variations  in  beam.  Results  for  the  later  are  shown 
in  section  8.0  except  where  noted. 


7.0  Multi-Objective  Genetic  Algorithm  Optimization  Technique 

Anticipating  a  design  space  with  many  competing  objectives  of  performance  and 
effectiveness,  it  was  decided  early  on  we  would  need  an  optimization  technique  to 
incorporate  into  FIPER  that  was  well  suited  to  handle  those  competing  objectives.  A 
Multi-Objective  Genetic  Algorithm  (MOGA)  called  Epsilon-MOEA  was  chosen  as  the 
ideal  solution.  Dr.  David  Powell  from  Elon  University  completed  this  integration  in 


FIPER.  Appendix  F  outlines  his  integration  work  on  the  STTR  project.  An  in-depth 
paper  is  available  that  describes  the  technique  used.  It  is  called  “A  Fast  Multi-objective 
Evolutionary  Algorithm  for  Finding  Well-Spread  Pareto-Optimal  Solutions”  and  can  be 
downloaded  from  http://www.iitk.ac.in/kangal/pub.htm  . 

8.0  Analysis 

8.1  Analysis  overview 

Once  integration  of  the  entire  MDO  system  was  complete,  design  exploration 
techniques  were  added  to  the  integrated  process.  These  techniques  were  used  to 
explore  the  design  space  in  search  of  optimum  ship  designs.  FIPER  allows  the 
user  to  quickly  integrate  design  exploration  techniques  into  any  integrated 
process  by  dragging  and  dropping  preloaded  “design  drivers”  into  the  workflow. 
These  design  drivers  act  as  engines  to  automate  the  execution  of  the  integrated 
process  by  substituting  values  into  the  input  parameters  of  interest.  A  user  can  set 
up  a  design  driver  to  examine  a  set  of  predefined  runs,  search  for  an  optimal 
answer,  or  measure  uncertainties  in  the  integrated  process  and/or  models. 
Iterating  through  a  sequence  of  runs  chosen  by  the  design  driver,  the  integrated 
process  returns  results  for  each  run.  Once  FIPER  executes  a  predefined  design 
driver,  it  continues  until  an  optimal  solution  is  obtained  or  the  maximum  number 
of  allowed  runs  is  reached. 

8.2  Requirements 

In  order  to  measure  performance  and  effectiveness,  the  MPFF  ship  class  needed 
to  meet  certain  requirements.  John  Covington  from  Northrop  Grumman  provided 
the  requirement  matrix  shown  in  Figure  21. 
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RAST-Recovery,  Assist,  Securing  and  Traversing  system.  Mechanical  helo  recovery  and  handling  system. 
CONREP-  Connected  Replenishment.  Two  ships  steaming  side  by  side  transferring  supplies 
VERTREP-  Vertical  replenishment.  Transfer  of  supplies  between  ships  using  helicopters. 
Strikedown-Transfer  of  supplies  from  initial  landing  or  laydown  area  to  below  decks. 

RAS -Replenishment  at  sea,  includes  CONREP,  VERTREP  and  Strikedown  operations.  Notice  RAS 
requirements  are  the  intersection  of  requirements  for  these  operations. 


Figure  21  -  Requirements  Matrix 

In  order  to  effectively  evaluate  the  numerous  requirement  cases,  many  of  the 
requirements  were  consolidated  and  enveloped  to  produce  an  overarching  set  of 
constraints.  Constraints  for  vertical  displacement  and  velocity  at  the  Helo  VTOL, 
VERTREP,  and  RAS  points  (see  descriptions  in  Figure  21)  were  chosen,  as  well 
as  the  pitch  and  roll  constraints  at  the  Helo  VTOL.  The  vertical,  lateral,  and 
longitudinal  accelerations  at  each  point  were  not  included  in  the  constraint  list;  it 
was  verified  that  for  all  cases  these  parameters  did  not  come  close  to  violating  the 
required  maximum  values. 

While  typical  ship  design  analysis  calls  for  examining  a  ship  at  several  sea  states, 
the  team  chose  a  sea  state  of  about  level  5  to  run  all  the  analysis.  This  provided  a 
consistent,  coherent  set  of  results  and  demonstrated  the  process  of  the  integrated 
MDO  analysis.  In  phase  II  of  the  project,  a  more  complete  set  of  sea  states,  as 
well  as  a  larger  set  of  requirements,  could  be  scrutinized. 

8.3  Design  of  Experiments 

A  Design  of  Experiments  (DOE)  was  executed  on  the  integrated  process.  Figure 
22  shows  the  integrated  process  with  the  DOE  design  driver  added. 


Figure  22  -  Work  Flow  with  DOE  Added 


The  DOE  was  a  Latin  Hypercube  analysis  of  30  points.  Figure  23  shows  the 
design  driver  editor  for  the  DOE. 


Figure  23  -  DOE  Editor 

The  DOE  is  used  to  quickly  search  the  design  space  for  optimum  answers.  By 
running  a  matrix  of  30  different  ship  designs,  we  were  able  to  evaluate  ships  of 
varying  sizes  and  investigate  their  performance  and  effectiveness  as  measured 
against  the  requirements.  Figure  24  shows  the  list  of  input  parameters,  or  factors 
as  they  are  termed  in  DOE,  of  interest  in  our  design  study. 


Figure  24  -  DOE  factors 

Upon  completing  a  DOE,  the  factors  could  be  measured  against  key  responses  to 
determine  their  influence  on  that  response.  The  Pareto  chart  effectively  captures 
this  metric  as  seen  in  Figures  25  and  26. 


Figure  25  -  Pareto  Plot  of  factors  %  effect  on  Lifecycle  Cost 


Figure  26  -  Pareto  Plot  of  factors  %  effect  on  Lifecycle  Cost 

As  can  be  seen  in  Figure  25,  the  biggest  influence  on  lifecycle  cost  is  the  size  of 
the  ship,  or  Beam-LPB,  which  is  the  interaction  of  the  ship’s  length  and  beam. 
Likewise,  Figure  26  shows  the  largest  driver  of  the  Helo  Deck  vertical 
displacement  would  be  wave  height,  which  is  a  fairly  intuitive  result  if  wave 
height  is  varied. 

Finally,  the  Lifecycle  cost  and  Helo  deck  vertical  displacement  as  a  function  of 
Beam  and  Length  were  examined.  Figure  27  and  28  show  the  results  in  a  3-D 
plot. 


Figure  27  -  Lifecycle  Cost  versus  Ship  Length  and  Beam 
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Figure  28  -  Helo  Deck  Max  Vertical  Displacement  versus  Ship  Length  and  Beam 


Complete  Results  for  all  30  DOE  runs  can  be  seen  in  Appendix  G. 

8.4  Optimization 

Once  a  DOE  analysis  was  run,  a  viable  (i.e.  best  answer)  starting  point  could  be 
chosen  for  initialization  of  an  optimization  run.  The  table  in  Figure  29  shows  the 
starting  design  point  chosen  and  the  associative  starting  constraint  values. 


Initial  Design 

Design  Variables 

Lower  Bound 

Initial  Value 

Upper  Bound 

SS  ENG  FRIG  FAC 

0.75 

0.9 

0.99 

SS  ENG  RPM 

800 

900 

999 

SS  ENG  MASS  FL 

4 

5.39775 

6 

SS  ENG  PWR  AVAIL 

3500 

3952.21 

4500 

SS  ENG  SFC 

0.1 

0.188566 

0.3 

SS  ENG  EXH  TEMP 

400 

443.889 

500 

SS  ENG  BARE  WT 

25 

29.6381 

50 

LBP 

230 

266.6 

300 

Wave  Height 

3 

4 

5 

Responses 

Lower  Bound 

Initial  Value 

Upper  Bound 

Viola 

CLIFE 

57845.64612 

Nc 

HLVerDspMax 

2.36 

2.6 

Nc 

HLVerVelMax 

1.36 

2.1 

Nc 

MaxPitch 

0.73 

3 

Nc 

Max  Roll 

4.8 

5.1 

Nc 

VRVerDspMax 

1.32 

2.1 

Nc 

VRVerVelMax 

0.91 

2.1 

Nc 

Figure  29  -  Table  of  initial  design  parameters 

Starting  from  this  point,  a  first  optimization  was  done  using  the  Hooke-Jeeves 
technique.  The  table  outlines  the  initial,  upper,  and  lower  bound  values  for  each  of 
the  design  parameters.  Figure  30  shows  the  optimization  design  driver  editor  for 
this  technique. 


Figure  30  -  Hooke-Jeeves  Optimization  Editor 

A  total  of  101  design  evaluations  were  completed  by  the  optimizer,  and  a  total  of 
97  feasible  designs  were  found.  Figures  3 1  and  32  show  the  history  chart  of  the 
lifecycle  cost  and  Helo  Deck  vertical  displacement  for  all  101  designs. 


Figure  31  -  Lifecycle  Cost  over  101  runs 


Figure  32  -  Helo  Deck  Max  Vertical  Displacement  over  101  runs 

The  table  in  Figure  33  shows  the  final  optimum  ship  design,  based  on  the  given 
constraints,  found  by  the  Hooke-Jeeves  technique. 


Optimized  Design 

Design  Variables 

Lower  Bound 

Initial  Value 

Upper  Bound 

SS  ENG  FRIG  FAC 

0.75 

0.99 

0.99 

SS  ENG  RPM 

800 

999 

999 

SS  ENG  MASS  FL 

4 

4 

6 

SS  ENG  PWR  AVAIL 

3500 

4500 

4500 

SS  ENG  SFC 

0.1 

0.1 

0.3 

SS  ENG  EXH  TEMP 

400 

400 

500 

SS  ENG  BARE  WT 

25 

25 

50 

LBP 

230 

230 

300 

Wave  Height 

3 

3 

5 

Responses 

Lower  Bound 

Initial  Value 

Upper  Bound 

Violation 

CLIFE 

54275.22037 

No 

HLVerDspMax 

1.82 

2.6 

No 

HLVerVelMax 

1.06 

2.1 

No 

MaxPitch 

0.67 

3 

No 

MaxRoll 

3.8 

5.1 

No 

VRVerDspMax 

1.14 

2.1 

No 

VRVerVelMax 

0.81 

2.1 

No 

Figure  33  -  Final  Optimum  Design  found  by  the  Hooke-Jeeves  technique 

Figure  34  shows  the  overall  improvement  for  Lifecycle  cost  and  Helo  Deck 
maximum  vertical  displacement. 


Objective  component 

Difference 

Improvement 

CLIFE 

3570.425757 

6% 

HLVerDspMax 

0.54 

23% 

Figure  34  -  Measured  Improvement  between  initial  ship  design  and  final  ship  design. 

In  addition  to  the  Hooke-Jeeves  optimization  analysis,  the  newly  integrated  Multi- 
Objective  Genetic  Algorithm  (MOGA)  technique  was  also  used  to  investigate  the 
ship  design  space  in  search  of  an  optimum.  While  the  MOGA  technique  was 
integrated  and  applied  to  the  integrated  system,  insufficient  time  remained  to 
adequately  evaluate  the  large  number  of  runs  usually  required  to  execute  an 
effective  MOGA  analysis.  On  a  first  order  problem  such  as  this,  the  results  would 
be  quite  close  to  those  found  by  the  Hooke-Jeeves  method.  Further  exploration  of 
this  technique  could  be  done  in  subsequent  phases. 


8.5  Uncertainty  Analysis 

Expanding  on  the  optimization  analysis,  a  Monte  Carlo  analysis  was  performed  to 
measure  the  effect  of  uncertainty  on  the  weight,  cost,  vertical  maximum 
displacement  at  the  helo  deck  of  the  ship,  etc.  Below  are  the  random  variables  (i.e. 
parameters  with  associative  uncertainty)  and  those  responses.  Each  random 
variable  was  given  a  normal  distribution.  The  initial  design  point  was  taken  as  the 
mean,  and  an  appropriate  standard  deviation  was  given.  Two  hundred  design 
simulations  were  executed  using  a  descriptive  sampling  technique.  The 
descriptive  sampling  technique  allowed  the  user  to  drastically  reduce  the  number 
of  Monte  Carlo  simulation  needed  to  provide  an  accurate  picture  of  uncertainty. 


Monte  Carlo  Simulation  Results 


Descriptive  Sampling 
200 

RANDOM  VARIABLES: 

SS  ENG  BARE  WT 

Distribution 

Normal 

Mean 

25.0 

Standard  Deviation 

2.96381 

Coefficient  of  Variation 

0.1185524 

Fixed  Parameter 
Standard  Deviation 

Wave  Height 

Distribution 

Normal 

Mean 

3.0 

Standard  Deviation 

0.4 


Sampling  Technique: 
Number  of  Simulations: 


Coefficient  of  Variation 


0.133333333333333 


Fixed  Parameter 
Standard  Deviation 

LBP 

Distribution 

Normal 

Mean 

235.0 

Standard  Deviation 
2.0 

Coefficient  of  Variation 
0.008510638297872 

Fixed  Parameter 
Standard  Deviation 

Lower  Truncation 
230.0 

SS  ENG  EXH  TEMP 

Distribution 

Normal 

Mean 

400.0 

Standard  Deviation 
44.38890000000001 

Coefficient  of  Variation 
0.11097225 

Fixed  Parameter 
Standard  Deviation 

SS  ENG  SFC 

Distribution 

Normal 

Mean 

0.188566 


Standard  Deviation 
0.0188566 

Coefficient  of  Variation 

0.1 

Fixed  Parameter 
Standard  Deviation 

SS  ENG  MASS  FL 

Distribution 

Normal 

Mean 

4.0 

Standard  Deviation 
0.539775 

Coefficient  of  Variation 
0.13494375 

Fixed  Parameter 
Standard  Deviation 

SS  ENG  PWR  AVAIL 

Distribution 

Normal 

Mean 

4500.0 

Standard  Deviation 
395.221 

Coefficient  of  Variation 
0.087826888888889 

Fixed  Parameter 
Standard  Deviation 

SS  ENG  FRIC  FAC 

Distribution 

Normal 

Mean 

0.99 


Standard  Deviation 
0.09 

Coefficient  of  Variation 
0.090909090909091 

Fixed  Parameter 
Standard  Deviation 

SS  ENG  RPM 

Distribution 

Normal 

Mean 

999.0 

Standard  Deviation 
90.0 

Coefficient  of  Variation 
0.09009009009009 

Fixed  Parameter 
Standard  Deviation 


RESPONSES: 

HLVerDspMax 

Mean 

1.8162999999999994 

Standard  Deviation 
0.2420293391409915 

Minimum 

1.14 

Maximum 

2.5 


Probability  less  than  upper  limit  2.6 

1.0 


MaxPitch 

Mean 

0.6550500000000001 

Standard  Deviation 
0.09949620583155105 

Minimum 

0.41 

Maximum 

1.37 

Probability  less  than  upper  limit  3.0 
1.0 

VRVerVelMax 

Mean 

0.7900999999999999 

Standard  Deviation 
0.10606715422801799 

Minimum 

0.49 

Maximum 

1.1 

Probability  less  than  upper  limit  2.1 
1.0 

CLIFE 

Mean 

54725.74988611083 

Standard  Deviation 
207.12540937167617 

Minimum 

54214.3771529129 

Maximum 

55367.9184658241 


VRVerDspMax 


Mean 

1.1192499999999996 

Standard  Deviation 
0.14972315322977048 

Minimum 

0.7 

Maximum 

1.55 

Probability  less  than  upper  limit  2.1 
1.0 

MaxRoll 

Mean 

3.7650500000000005 

Standard  Deviation 
0.49018404655546205 

Minimum 


Maximum 

4.96 

Probability  less  than  upper  limit  5.1 

1.0 

HLVerVelMax 

Mean 

1.0544 

Standard  Deviation 
0.14096095186167248 

Minimum 

0.66 

Maximum 

1.45 

Probability  less  than  upper  limit  2.1 
1.0 


As  can  be  seen  in  the  tables  above,  based  on  the  uncertainty  given,  all  our 
constraints  were  satisfied  with  100%  probabilities;  and  our  lifecycle  cost  ranged 
between  a  minimum  of  54214  and  a  maximum  of  55367  -  a  maximum  variation 
of  about  1%.  Again,  this  was  done  as  a  first  order  analysis. 

Figures  36-38  show  the  histogram  plots  of  the  some  of  those  responses. 


Figure  36  -  Histogram  of  Monte  Carlo  Runs  for  the  Weight  Response 


Figure  37  -  Histogram  of  Monte  Carlo  Runs  for  the  Lifecycle  Cost  Response 


■  ^  Frequency  of  HLVerDspMax 


Bi)[x 


Figure  37  -  Histogram  of  Monte  Carlo  Runs  for  the  Helo  Deck  Max  Vertical 

Displacement  Response 


9.0  Phase  II 

Phase  II  work  will  be  discussed  in  the  Phase  II  work  plan  to  be  delivered  by  February  4*, 
2004. 

1 0.0  Summary 

The  success  of  the  work  on  this  project  can  be  measured  in  a  couple  different  ways.  If 
the  accomplishments  are  measured  against  the  objectives  outlined  in  the  section  2.0,  the 
following  results  can  be  stated: 

1.  The  team  members  identified  three  analysis  tools:  ASSET,  SMP,  and  an  Excel 
cost  model  to  measure  ship  performance  and  effectiveness. 

2.  The  MPFF  ship  class  was  verified  as  a  program  of  interest  to  the  Navy  and  MPFF 
models  were  obtained  or  developed  for  the  project. 

3.  Each  model  was  integrated  into  the  FIPER  framework  under  a  single  workflow. 

4.  The  integrated  workflow  allowed  the  users  to  quickly  apply  design  exploration 
techniques  such  as  design  of  experiments,  optimization,  and  quality  engineering 
tools. 

5.  A  Multi-Objective  Genetic  Algorithm  (MOGA)  was  identified  as  an  optimization 
technique  of  choice  and  integrated  into  the  FIPER  framework. 

6.  Uncertainty  analysis  using  Monte  Carlo  technique  was  performed  and  measured 
against  Lifecycle  cost. 

7.  Northrop  Grumman  has  stated  that  other  classes  of  ships,  such  as  DDX,  are 
potential  beneficiaries  of  an  integrated  MDO  analysis  ship  design  system 
implemented  in  FIPER.  By  taking  the  current  system  and  enhancing  and 
expanding  it  in  future  phases,  a  broader  base  of  industry  and  institutional 
candidates  could  benefit  from  the  possibilities. 

Evaluating  the  project  in  terms  of  its  overall  usefulness  and  impact  is  another 
measure  of  the  projects  success.  The  team  was  able  to  take  isolated  ship  design 
disciplines  and  bring  them  under  a  single  framework.  The  models  were  able  to 
communicate  with  each  other  through  FIPER  after  their  initial  integration.  And,  it 
should  be  noted  that  this  integration  was  not  a  “hard  coded,”  single-use  integration 
case.  Due  to  FIPER’ s  flexible  framework,  different  models  can  be  integrated  without 
great  pains.  In  addition,  applying  design  exploration  techniques  was  done  in  a  simple 
drag  and  drop  action.  These  capabilities  allow  the  team  to  provide  an  integrated 
naval  design  environment  one  else  can.  It  has  the  ability  to  integrate  tools  not  only  in 
the  localized  analysis  environment  (i.e.  a  single  engineering  group),  but  also  across 
different  design  groups,  departments,  as  well  as  outside  vendors. 

While  the  analysis  performed  under  this  project  would  not  hold  up  to  scrutiny  under 
a  true  ship  design  effort,  it  did  demonstrate  the  ease  in  which  a  system  could  be 
rapidly  assembled  and  the  ability  to  apply  design  exploration  techniques  to  that 


process.  Once  integrated,  all  design  driver  capabilities  in  PIPER  could  be  brought  to 
bear  on  the  design  system.  Optimization,  DOE,  quality  engineer,  etc.  could  all  be 
used  and  would  not  require  a  separate  integration. 

Moving  forward,  the  next  phase  of  the  project  will  lead  to  the  development  of  more 
robust  analysis  models,  integration  of  more  analysis  tools  to  measure  ship 
performance  and  effectiveness,  tight  coupling  of  those  analysis  tools  (i.e.  integration 
component  interfaces  that  are  specific  to  the  tools,  like  SMP,  to  allow  even  quicker 
integration  and  greater  ease  of  use),  and  the  demonstration  of  the  ability  to  handle 
tool  integration  through  the  internet  in  a  secure  fashion. 


Appendix  A 


11.0  Project  Work  Summary 

11.1  Period  Covering  7/1/03  -  9/30/03 

Engineous  Software  received  notification  that  we  had  been  recommended  for  an 
award  for  STTR  #  N03-T026  by  John  Williams  on  June  11,  2003.  We  received  a 
purchase  order  for  this  award  on  June  26,  2003.  As  soon  as  we  received  word  of 
the  recommendation,  we  immediately  started  implementing  the  required 
agreements  with  MIT  to  address  intellectual  property  rights,  confidentiality 
requirements,  product  licensing  requirements  and  other  matters  pertaining  to  the 
subcontracting  relationship  between  Engineous  and  MIT.  Since  Northrop 
Grumman  was  already  a  customer  of  Engineous,  and  since  they  would  not  be 
getting  paid  (except  for  expense  reimbursement),  no  documents  needed  to  be 
signed  with  them.  Unfortunately,  it  took  from  6/20  to  9/03  to  get  the  referenced 
documents  agreed  upon  and  signed  and  this  put  us  a  little  behind  schedule. 
However,  we  did  not  expect  any  problems  with  completion  of  the  outlined  project 
by  the  scheduled  due  date. 

On  September  9*  we  officially  kicked  off  the  program  with  a  conference  call. 
During  this  call  a  lot  of  ground  was  covered.  For  example: 

•  We  reviewed  the  objectives  proposed  in  the  STTR. 

•  A  demonstration  of  the  Engineous  technology  that  would  be  used  as  a 
framework  to  integrate  the  different  tools  was  given. 

•  A  discussion  was  held  on  exactly  which  ship  synthesis,  mission  effectiveness 
and  ship  design  tools  would  be  integrated. 

•  We  discussed  which  design  currently  at  NSWC-CD  we  would  use. 

•  A  date  was  set  for  a  meeting  at  Engineous  Headquarters  for  October  7*  &  8*. 

During  September,  the  Northrop  Grumman  team  received  internal  funding  for  two 
people  to  support  the  effort  on  the  STTR.  Aldo  Kusmik  from  NUWC  also 
received  support  from  his  management  for  participation  and  brought  in  another 
person  to  be  trained  on  Engineous  technology  to  support  this  program.  See 
Appendix  B  for  an  updated  team  list. 

In  the  months  of  October  and  November,  each  member  of  the  team  was  trained  on 
the  FIPER  framework  and  had  it  loaded  on  their  computer.  During  this  time,  we 
accomplished  the  following  items: 

•  Team  members  became  proficient  on  the  use  and  understanding  of  the  FIPER 
technology. 

•  Developed  a  list  of  codes  currently  being  used  and  how  they  interacted  with 
each  other  at  naval  ship  design  locations.  Codes  for: 

o  Mission  effectiveness 
o  Mission  analysis 
o  Ship  design 


•  Determined  the  feasibility  of  integrating  these  codes. 

•  Identified  the  ship  that  would  be  used  as  an  example. 

11.2  Period  Covering  10/1/03  -  12/31/03 

A  STTR  team  meeting  was  held  at  Engineous  Software  headquarters  on  October 
7*  and  8*  (See  Appendix  B  for  a  list  of  team  members).  This  meeting  brought 
together  the  team  members  from  Northrop  Grumman,  MIT,  NUWC  and  Elon 
University.  Team  members  received  training  on  Engineous ’s  integration  software 
PIPER.  Meetings  were  also  held  to  discuss  the  direction  of  the  project  including: 

•  Identifying  ASSET,  SMP,  SIMSmart,  Signatures  and  MIT’s  Excel  cost 
model  as  the  analysis  tools  of  choice 

•  Identifying  ECS  as  our  model  ship 

•  Identifying  Multi-Objective  Genetic  Algorithm  (MOGA)  as  the 
optimization  technique  of  choice  for  ship  analysis 

Northrop  Grumman  was  in  charge  of  obtaining  the  ship  models  for  the  ECS 
program.  Asset  would  be  obtained  directly  from  the  ONR.  SMP  would  be 
provided  by  NUWC.  The  MIT  Excel  cost  model  and  Signatures  would  be 
provided  by  MIT.  Finally,  SIMSmart  would  be  provided  by  Northrop  Grumman. 
A  weekly  conference  call  was  established  for  every  Thursday  at  10  am  EST  to 
communicate  on  the  project  progress  among  team  members.  Each  team  member 
returned  home  with  a  copy  of  PIPER  for  use  on  the  project. 

A  working  model  of  SIMSmart  was  readily  available  and  integration  of  the  model 
into  PIPER  was  begun  immediately.  Justin  Vianese  from  Engineous  traveled  to 
Northrop  Grumman  Ship  Systems  in  Pascagoula,  Mississippi  November  12*- 14* 
to  assist  in  the  integration  of  the  SIMSmart  into  PIPER.  During  this  visit,  it  was 
determined  that  the  LCS  models  for  SMP  and  ASSET  would  not  be  available, 
since  Northrop  Grumman  was  entering  an  unsolicited  bid  to  the  Navy  on  that 
project.  Northrop  suggested  using  the  Multipurpose  Force  Future  (MPFF)  or 
Auxiliary  Oilier  Experiment  (AEX)  ship  models  instead. 

In  late  November,  the  team  determined  that  the  SIMSmart  model  was  a  good 
detailed  analysis,  but  would  not  integrate  well  with  the  SMP  and  ASSET  models, 
which  dealt  with  much  higher  level  analysis.  At  that  point,  work  with  SIMSmart 
ceased.  It  was  also  determined  that  due  to  Signatures  classified  status;  the  team 
would  not  be  able  to  obtain  a  copy.  MIT  found  that  no  unclassified  software 
existed  that  could  provide  the  stealth  analysis  needed.  Therefore,  stealth  analysis 
was  dropped  from  the  list  of  tools.  Northrop  identified  MPFF  as  the  best 
replacement  ship  candidate  for  the  STTR  project. 


On  November  2  U‘  Rick  Recuparo  and  Justin  Vianese  from  Engineous  gave  a 
project  update  to  ONR  in  Washington  D.C.  Attending  the  update  from  ONR  were 


Katherine  Drew,  Bruce  Wintersteen,  and  Luise  Couchman.  The  team’s  progress 
to  date  and  future  program  goals  were  presented.  The  presentation  included: 


•  A  review  of  the  proposed  objectives 

•  Overview  of  the  PIPER  integration  software 

•  Identification  of  the  analysis  tools 

•  Overview  of  the  MPFF  ship  class  (operation  roles) 

•  MDO  analysis  technique 

•  Identification  of  requirements  and  measures  of  effectiveness 

•  Cost  analysis 

•  Integration  scheme 

•  Summary  of  work  done  and  future  work 

Due  to  a  last  minute  conflict  of  schedules,  Northrop  Grumman  was  not  able  to 
attend  the  meeting  to  present  the  MPFF  overview.  A  follow  up  web  presentation 
for  ONR  was  done  on  December  10*  to  present  this  portion.  The  full  presentation 
is  included  in  Appendix  B  of  this  report. 

At  the  end  of  December  Northrop  Grumman  determined  that  the  LHD8  ASSET 
model,  one  of  the  three  classes  of  ships  Northrop  was  combining  as  a  baseline  for 
their  MPFF  project,  was  to  be  used  for  our  analysis.  Northrop  also  determined 
that  the  SMP  model  would  need  to  be  created  for  LHD8,  as  no  model  was 
currently  available.  With  the  help  of  MIT  and  NUWC,  Engineous  would  need  to 
create  this  model  and  integrate  it  with  the  ASSET  LHD8  model  and  MIT  Excel 
cost  model. 

There  was  also  a  change  in  the  team  as  well  in  December.  Rick  Recuparo  left 
Engineous  Software  to  pursue  another  opportunity.  He  left  on  amicable  terms  on 
December  12*.  Justin  Vianese  took  over  as  the  Principal  Investigator  at  that  time. 

The  team  spent  the  remainder  of  the  project  period: 

•  Developing  a  LHD8  SMP  model 

•  Integrating  the  LHD8  ASSET,  SMP,  and  Cost  models  into  the  FIPER 

•  Running  optimization  analysis  on  the  integrated  process 

•  Writing  a  Final  Report  documenting  complete  project  effort 

•  Developing  a  5  page  Phase  II  plan 

11.3  Period  Covering  1/1/04  -  2/2/04 

At  the  end  of  December,  Northrop  Grumman  determined  that  the  LHD8  ship  was 
to  be  used  in  our  MDO  analysis.  The  LHD8  model  was  provided  in  ASSET,  but 
the  LHD8  model  needed  to  be  created  in  SMP;  and  the  spreadsheet  needed  to  be 
adjusted  for  LHD8  as  well. 

Engineous  did  a  preliminary  integration  of  ASSET,  SMP,  and  the  MIT  cost 
spreadsheet  into  FIPER.  While  the  LHD8  model  was  available  for  the  ASSET, 
example  models  were  used  for  the  preliminary  integration  until  the  actual  models 


were  built.  The  MIT  cost  model  was  integrated  into  the  PIPER  framework  using 
piper’s  Excel  integration  component.  This  component  allows  the  user  to  specify 
which  data  he/she  would  like  to  change  in  the  spreadsheet  via  cell  locations,  and 
which  results  he/she  would  like  to  read  after  those  changes  are  made.  Thus,  the 
user  could  manipulate  spreadsheet  cells  of  interest  (e.g.  weight,  length,  crew  size, 
etc.)  and  see  the  effect  on  output  results,  such  as  overall  lifecycle  cost. 

ASSET  was  integrated  in  a  similar  manner,  by  taking  advantage  of  ASSET’S 
ability  to  communicate  directly  with  Excel.  ASSET  allows  a  user  to  develop  an 
Excel  spreadsheet  of  pertinent  ASSET  input  parameters  and  key  results,  and 
communicate  changes  to  ASSET  via  the  spreadsheet.  The  results  are  returned  to 
the  spreadsheet  once  ASSET  is  finished  executing  its  analysis.  Execution  of 
ASSET  can  be  controlled  from  within  Excel  by  leveraging  specific  Excel  macros 
provided  by  ASSET.  By  leveraging  this  interface  capability,  Engineous  was  able 
to  again  use  PIPER’ s  Excel  component  to  make  substitutions  in  an  Excel 
spreadsheet.  All  parameters  of  interest,  inputs  (e.g.  length,  etc.)  and  outputs  (e.g. 
weight,  etc.)  were  stored  in  the  Excel  spreadsheet,  which  communicated  directly 
with  PIPER.  Below  is  a  diagram  of  that  communication. 


ASSET 


ASSET  TO 


Excel  TO 
(To/Prom  ASSET) 


◄ - ► 


MS/Excel 


PIPER 


While  ASSET  and  the  cost  model  took  advantage  of  PIPER’s  Excel  component, 
SMP  was  integrated  using  PIPER’s  data  exchange  component.  The  data 
exchange  component  allows  information  stored  in  text  input  and  output  files  for 
SMP  to  be  written  and  read  in  and  out  of  PIPER.  The  data  exchange  component 
editor  is  used  to  identify  the  input  and  output  parameters  of  interest  by  allowing 
the  user  to  highlight  input  and  output  parameters  from  SMP’s  input  and  output 
files. 

SMP  Input  Pile  Data  Exchange  Example: 

#  RECORD  SET  4  -  Hull  particulars 

237.134  32.3088  7.9248  41194.800  24.9097  5.0000  0.0000 


The  above  highlighted  parameter.  Ship  Length,  could  be  identified  in  the  data 
exchange  parameter  so  PIPER  could  manipulate  this  parameter  to  produce  ships 
of  varying  length.  Similarly,  highlighting  a  parameter  in  the  data  exchange  editor 
from  a  sample  SMP  output  file  provides  PIPER  with  a  template  on  how  to  read 
parameters  from  SMP  as  they  are  generated  after  each  analysis.  So,  for  each  ship 


analysis  run,  say  with  varying  length,  PIPER  can  read  weight,  heave,  pitch,  sway, 
roll,  yaw,  etc. 

SMP  Output  File  Data  Exchange  Example: 

MAXIMUM  RESPONSES  AND  CONDITIONS 


RESPONSE  HEAVE  PITCH  SWAY  ROLL  YAW  PI  VAC  PI  LAC  P2VAC  P2LAC  P3VAC  P3LAC 
P4VAC  P4LAC 


(MAX.RSV)/TOE  1.11/8  0.86/10 
AT  SPEED  (KNOTS)  25.0  0.0 

AT  HEADING  (DEG)  75.  75. 


1.23/90  6.24/12  0.93/17  206.6/8  199.5/17  8.51/7  6.64/10  9.72/12  3.78/9  9.72/12  3.78/9 
25.0  10.0  25.0  10.0  25.0  25.0  0.0  25.0  0.0  25.0  0.0 

135.  105.  135.  75.  120.  75.  90.  90.  90.  270.  90. 


The  above  highlighted  parameters  provide  PIPER  with  the  results  of  pitch  and 
roll  for  the  ship.  After  each  analysis  of  a  different  ship  configuration  is  run,  these 
parameters  are  communicated  back  to  PIPER;  and  used  to  evaluate  the 
performance  and  effectiveness  of  the  ship  in  combination  with  all  the  other 
parameters  coming  out  of  ASSET  and  the  cost  model. 

After  linking  the  demonstration  models,  Engineous  worked  with  NUWC  and 
MIT  to  build  the  proper  LHD8  models  for  SMP  and  the  cost  models.  On  January 
15*,  Dave  Naehring  and  Justin  Vianese  from  Engineous  met  with  Dr. 
Chryssostomos  Chryssostomidis  at  MIT  in  Cambridge,  Massachusetts.  During 
the  meeting  Dr.  Chryssostomidis  reviewed  the  ASSET,  SMP,  and  cost  model’s 
input  and  output  parameters  of  interest  with  Dave  and  Justin.  The  data  flow 
to/from  ASSET,  SMP,  and  the  MIT  cost  model  were  identified. 

After  meeting  with  Dr.  Chryssostomidis,  and  with  significant  help  from  William 
Krol  at  NUWC,  Engineous  was  able  to  complete  the  development  of  uniform 
LHD8  models  for  ASSET,  SMP,  and  the  cost  model. 

After  completing  the  models,  the  new  SMP  model  and  cost  model  were 
integrated  into  PIPER  in  place  of  the  example  models  that  were  used  in  the  initial 
integration.  Once  the  new  models  were  integrated,  PIPER’ s  design  exploration 
techniques  were  used  to  investigate  the  design  space.  At  first,  length  was 
examined  and  a  Design  of  Experiments  (DOE)  analysis  was  run.  By  its  nature, 
the  DOE  allows  the  user  to  quickly  scan  the  design  space  to  identify  areas  that 
might  provide  significant  improvements  in  ship  design.  After  running  a  DOE,  a 
user  can  employ  an  optimization  technique  and/or  a  quality  engineering 
technique,  such  as  Monte  Carlo  analysis,  to  look  for  deterministic  and/or 
stochastic  optimums. 

By  trying  multiple  optimization  techniques,  including  the  Multi-objective 
Genetic  Algorithm  developed  by  Elon  University,  “optimum”  ship  designs  were 


obtained.  The  word  “optimum”  must  be  qualified  beeause  the  optimum  design 
obtained  was  based  on  certain  assumptions  and  a  limited  parameter  set  in  which 
to  explore  the  design  space.  Fewer  assumptions  and  greater  parameter  sets  would 
provide  a  superior  optimum  (i.e.  closer  to  the  true  optimum). 

A  Monte  Carlo  analysis  was  also  performed  to  investigate  the  effect  of 
uncertainty  on  performance  and  effectiveness.  FIPER  used  a  descriptive 
sampling  Monte  Carlo  technique  to  determine  the  reliability  of  the  ship  design 
measured  against  its  constraints.  That  is,  what  happens  to  key  measures  of 
performance/effectiveness  (e.g.  overall  lifecycle  cost)  when  uncertainties  are 
introduced  into  the  ship  design  (e.g.  ship  weight). 

A  complete  overview  of  all  results  and  further  descriptions  of  integration  can  be 
found  in  the  appropriate  sections  of  the  Final  Report. 

After  completion  of  the  analysis,  information  and  results  were  complied  in  a  final 
report.  A  review  of  the  project  and  the  results  will  be  presented  to  ONR  on 
February  3’^^’  in  Washington,  DC.  As  required,  the  Phase  II  work  plan  will  be 
provided  to  ONR  by  February  4*. 
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The  MPFF  Ship  Class  Presentation  by  Northrop  Grumman 
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Conclusion 
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BEYOND  TODAY  -  IMPLICATIONS  ON  THE 
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A  Distributed,  Component-Based  Integration  Environment  for 
Multidisciplinary  Optimal  and  Quality  Design 

Brett  A.  Wujek*,  Patrick  N.  Koch*,  Mark  McMillan,  Wei-Shan  Chiang 
Engineous  Software,  Inc. 

2000  CentrcGreen  Way,  Suite  100 
Cary,NC  27513 
Brett.  Wuiek@,engineous.com 

Technological  advancements  over  the  last  decade  have  progressed  to  the  point  where  the 
expectations  of  the  consumer  for  the  performance  and  quality  of  products  are  manifesting 
themselves  as  expectations  of  engineers  developing  these  products  for  the  capabilities  of 
their  design  environments.  Design  is  becoming  an  ever-increasingly  complex  activity 
involving  numerous  software  tools,  communication/transformation  of  data,  and 
collaboration  among  design  teams  both  within  and  among  corporations.  Engineers  are 
now  expecting  to  be  provided  with  software  tools  that  are  intuitive,  easy  to  use,  and  that 
can  interact  with  the  other  tools  involved  in  their  process  fairly  seamlessly.  In  reality, 
most  engineering  design  environments  fall  short  of  meeting  the  expectations  of  the 
engineers,  leaving  many  obstacles  to  overcome  in  their  effort  to  design  and  develop  the 
quality  products  demanded  by  the  customers.  There  are  numerous  developments 
underway  by  various  companies  and  organizations  trying  to  provide  this  ideal 
environment;  the  problem  with  most  of  them  is  that  they  continue  to  focus  on  the  all-in- 
one  solution,  attempting  to  provide  the  complete  solution  as  opposed  to  a  framework  that 
makes  the  complete  solution  possible  through  incorporation  of  best-of-breed  analysis  and 
design  tools.  This  paper  describes  the  Federated  Intelligent  Product  EnviRonment 
(FIPER),  an  environment  that  has  been  developed  to  serve  as  a  plug-and-play  framework 
for  engineers  to  incorporate  their  tools  of  choice  to  provide  services  within  the 
environment,  to  define  a  process  mapping  of  the  usage  of  these  services  (even  across 
enterprise  boundaries),  and  to  take  advantage  of  all  available  computing  resources  in  the 
execution  of  these  services  to  continually  improve  the  products  offered  to  consumers. 

I.  Introduction 

The  past  decade  has  witnessed  an  obvious  proliferation  of  software  tools  available  for  the 
various  activities  involved  in  multidisciplinary  analysis  and  design.  While  this  has 
resulted  in  greater  accuracy  and  finer  detail  in  the  level  of  modeling  of  physical 
phenomena,  it  has  also  added  to  the  complexity  of  the  process  overall.  The  mere 
existence  of  these  tools  does  not  mean  they  are  improving  the  productivity  of  the 
engineer;  in  fact,  the  opposite  may  very  well  be  true.  The  reason  for  this  is  that  there  is 
usually  no  single  entry  point  to  these  tools  or  a  common  way  to  interact  with  them, 
making  it  difficult  for  them  to  be  used  in  a  coordinated  fashion.  Moreover,  once  an 
ultimate  design  is  arrived  at,  it  is  often  very  difficult,  if  not  impossible,  to  determine  what 
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specific  tools  were  used  (in  particular,  what  versions  of  those  tools),  in  what  combination, 
and  what  were  the  sources  of  the  data  supplied  to  them.  The  problem  becomes  even 
more  overbearing  if  part  of  the  design  process  involves  contributions  from  design  teams 
in  geographically  disparate  locations  (possibly  even  other  corporations  altogether),  when 
firewalls  create  barriers,  security  is  of  utmost  concern,  and  data  transfer  among  tools 
becomes  cumbersome  and  error-prone.  Considering  all  of  these  obstacles,  engineers  are 
also  under  strict  time  constraints  to  meet  the  deadlines  governed  by  product  release 
cycles,  a  frustrating  predicament  given  that  numerous  design  evaluations  are  typically 
required  to  achieve  significant  design  improvement,  even  using  the  latest  intelligent 
optimization  and  reliability/robustness  algorithms  available.  The  mere  availability  of  an 
abundance  of  expensive,  high-powered  computing  hardware  does  not  ensure  that  it  can 
be  employed  effectively  during  the  design  process.  All  of  these  aforementioned 
problems  serve  to  counteract  the  ultimate  goal  of  the  designer  in  trying  to  continually 
improve  the  product  by  incorporating  the  latest  technologies  so  that  the  expectations  of 
the  customer  are  met  or  even  exceeded.  The  solution  is  not  more  or  even  better  design 
tools  -  the  solution  is  a  framework  that  provides  a  solid  foundation  for  overcoming  these 
problems.  The  requirements  for  this  type  of  framework  continue  to  be  established  as  the 
problems  and  obstacles  become  more  clearly  understood*’^. 

Recognizing  the  need  for  such  a  framework,  Engineous  Software  has  teamed  with 
General  Electric,  Goodrich,  Parker  Hannifin,  Ohio  University,  the  Ohio  Aerospace 
Institute,  and  Stanford  University  in  a  four-year  collaborative  effort  to  develop  a 
Federated  Intelligent  Product  EnviRonment  (FIPER)"*,  a  project  sponsored  by  the 
National  Institute  for  Standards  and  Technology  (NIST)  Advanced  Technology  Program 
(ATP).  The  FIPER  joint  venture  team  is  beginning  its  third  year  of  work,  with  the 
various  team  members  (and  additional  sub-contractors)  investigating  different  aspects  of 
the  environment  and/or  services  to  be  provided  in  the  environment.  The  ultimate 
outcome  of  the  project  is  a  commercially  developed  and  supported  product  development 
environment  from  Engineous  Software.  The  remainder  of  this  paper  provides  a  high- 
level  overview  of  this  environment,  with  particular  focus  on  the  use  of  this  environment 
for  optimal  and  quality  design.  Programs  in  place  for  the  early  application  of  this 
environment  in  industry  are  also  discussed. 

II.  FIPER 

FIPER  has  been  developed  to  provide  a  framework  to  overcome  the  aforementioned 
problems  in  existing  design  environments.  For  continuity,  we  will  consider  each  of  the 
issues  and  describe  how  FIPER  addresses  them. 

a)  “no  single  entry  point  to  these  tools  or  a  common  way  to  interact  with  them  ” 

FIPER  is  a  component-based  framework  that  offers  a  common  Java-based  wrapping 
mechanism  and  uses  XML  descriptors  to  allow  components  to  express  the  services  they 
provide,  information  required  to  define  how  to  use  those  services  (properties),  and  the 
inputs/outputs  (parameters)  they  expose  to  the  environment  (for  other  services  to  interact 
through).  One  of  the  fundamental  aspects  of  FIPER  is  that  anyone  can  develop  his/her 


own  components  (i.e.  wrapped  tools)  to  populate  the  PIPER  environment  with  serviees 
geared  toward  their  speeific  problems.  (Consequently,  PIPER  is  not  limited  to  the 
engineering  design  domain,  but  ean  theoretieally  be  applied  in  other  domains  such  as 
manufacturing  or  finance  -  it  is  all  a  matter  of  the  components  incorporated  and  the  types 
of  services  they  provide.  To  this  point  the  emphasis  has  been  on  the  engineering  design 
domain).  Por  example,  Ohio  University  has  developed  a  Cost  Modeling  eomponent  to 
provide  a  eost  estimation  service  within  the  environment^.  Other  PIPER  team  members, 
ineluding  Engineous  Software,  are  developing  various  eomponents  to  provide  different 
serviees  in  the  PIPER  environment,  ineluding  but  not  limited  to: 


Engineering  Analysis 

Components 

Design  Driver  Components 

CAD 

CAE 

Data  Exchange 

Excel 

Cost  Estimation 

Statistieal  Analysis 

Design  Of  Experiments 

Optimization 

Design  for  Six  Sigma 
(Reliability/Robustness) 

MDO  Algorithms 

Knowledge-Based  Engineering  (KBE) 

Again,  the  independence  of  eomponents  from  the  framework  must  be  emphasized.  It  is 
critieal  that  engineers  have  the  freedom  to  incorporate  their  own  preferred  tools  not  only 
for  the  analysis  aspeets  of  the  process,  but  also  for  the  design  improvement  functionality. 
The  philosophy  is  that  if  you  have  it  and  you  like  it,  you  can  use  it  -  if  not,  you  ean  find  it 
from  somewhere  else  and  it  will  still  work. 

PIPER  serves  as  a  “host”  for  the  eomponents  providing  these  serviees  through  the 
concept  of  a  Library.  The  PIPER  Library  is  a  virtually  eentralized  and  physieally 
distributed  repository  for  publishing  (storing),  searehing  for,  and  retrieving  eomponents, 
essentially  providing  the  eapability  to  collaborate  by  sharing  the  serviees  offered  by  the 
components  (even  among  different  business  divisions  or  independent  organizations). 

One  of  the  primary  aspeets  of  the  Library  is  that  it  is  version  eontrolled,  a  eritieal 
capability  to  ensure  that  as  eomponents  are  updated,  references  to  the  use  of  these 
components  do  not  beeome  “stale”  and  invalid. 

b)  “very  difficult,  if  not  impossible,  to  determine  what  specific  tools  were  used  (in 
particular,  what  versions  of  those  tools),  in  what  combination,  and  what  were  the 
sources  of  the  data  supplied  to  them  ” 

PIPER  allows  an  engineer  to  assemble  components  together  into  a  workflow  that  models 
his/her  design  proeess.  Workflow  is,  in  general,  a  very  powerful  and  flexible  way  of 
expressing  what  needs  to  be  done,  in  what  sequenee,  and  what  the  data  requirements  are; 
its  applieation  to  engineering  design  is  natural  and  has  tremendous  potential^.  In  PIPER, 
a  simple  Desktop  interfaee  provides  a  means  for  building  these  FIPER  models  through  a 
drag-and-drop  mechanism,  with  convenient  ways  to  specify  the  properties  and  parameters 
for  each  of  the  eomponents  in  the  model,  essentially  defining  both  eontrol  flow  and  data 
flow  (through  parameter  mapping).  The  components  referenced  in  the  model  being 
developed  ean  reside  in  the  PIPER  Library  or  in  a  file  system,  with  aeeessibility  limited 


by  whatever  aecess  permissions  were  supplied  when  the  eomponent  was  published.  Just 
as  components  are  published  for  others  to  use  and  extend,  so  too  can  model  be  published 
to  the  FIPER  Library  (with  access  permissions)  for  others  to  use  if  desired. 


Figure  2:  Building  Models  in  FIPER 

c)  “design  process  involves  contributions  from  design  teams  in  geographically 
disparate  locations  (possibly  even  other  corporations  altogether)  ” 

As  described  above,  the  FIPER  Library  provides  a  means  for  people  to  publish 
components  and  models  to  make  them  available  for  use  by  anyone  who  has  access  to  that 
Library.  It  is  envisioned  that  FIPER  will  provide  inter-organization  collaboration  by 
allowing  organizations  to  establish  connections  among  their  Libraries.  Thus,  models 
could  actually  contain  references  to  components  (or  other  models)  which  reside  in  a 
remote  Library,  again  with  accessibility  limited  by  whatever  access  permissions  were 
supplied  when  the  component  was  published  (or  by  stricter  permissions  established  by 
the  Library  relationships).  These  so-called  Business-to-Business  (B2B)  relationships  are 
becoming  evermore  common,  and  thus  this  capability  is  a  primary  ultimate  goal  of 
FIPER,  with  prototype  capabilities  currently  being  tested. 

d)  “mere  availability  of  an  abundance  of  expensive,  high-powered  computing 
hardware  does  not  ensure  that  it  can  be  employed  effectively  during  the  design 
process  ” 

The  FIPER  infrastructure  includes  all  of  the  necessary  modules  for  handling  data  communication 
and  storage  and  process  management.  Built  on  the  Java  2  Enterprise  Edition  (J2EE)  platform  as 
a  solid  foundation^’®,  the  FIPER  infrastructure  is  embodied  by  the  combination  of  a  Problem 
Solving  Environment  (PSE)  and  FIPER  Stations. 

The  PSE  is  essentially  an  application  server  that  provides: 

•  a  Workflow  Engine  for  interpreting  and  managing  process  flow  to  create  work  items 

•  a  Context  Manager  for  assembling  the  necessary  input  data  for  each  work  item 

•  a  Dispatcher  for  determining  which  FIPER  Station  the  work  item  should  be  sent  to 


•  a  Results  Manager  for  processing  results  from  the  work  items 

Any  organization  with  a  PSE  can  collaborate,  or  share  services,  with  any  other  organization  with 
a  PSE  (i.e.  B2B  collaboration). 

The  PIPER  Stations  are  computers  in  the  network  that  have  been  registered  with  the  PSE  to 
handle  the  execution  of  work  items,  essentially  consisting  of  a  lightweight  framework  for  receiving 
work  items,  communicating  with  the  Library,  executing  components  (likely  launching 
corresponding  back-end  software  applications),  and  returning  results.  The  PSE  dispatches  work 
Items  to  PIPER  Stations  based  on  a  defined  load-balancing  scheme,  distribution  strategy,  and/or 
affinities  (i.e.  operating  system  information,  third  party  software  licenses  supported,  machine 
name,  etc.)  defined  for  the  item  being  executed.  In  this  way,  an  organization  can  make  the  best 
use  of  its  computing  resources  by  making  them  available  to  do  work  within  the  PIPER 
environment. 


Figure  3:  The  Execution  of  a  Modei  in  the  FIPER  Environment 

It  is  important  to  note  that  jobs  can  be  submitted  to  the  PSE  to  execute  from  any  client. 
The  only  requirement  is  that  the  client  be  able  to  pass  the  XML  description  of  the  model 
to  the  PSE.  Thus,  thin  clients  such  as  custom  web  interfaces  or  even  PDA  devices  can 
load  a  model  from  a  FIPER  Library,  possibly  provide  new  input  values,  submit  it  to  the 
PSE,  and  receive  results  of  that  execution.  Moreover,  since  the  PSE  handles  all  aspects 
of  the  execution,  the  submitter  could  actually  exit  the  client  from  which  the  job  was 
submitted  and  at  a  later  time  use  another  interface  to  query  the  status  of  the  job  or  retrieve 
the  results. 


III.  Applications 


The  component-based  nature  of  PIPER  is  perfectly  suited  for  application  to  engineering 
design  problems.  By  applying  “design  driver”  components  such  as  optimization,  DOE, 
and  quality  engineering  techniques  to  an  integrated  collection  of  components  for  various 
analysis  tools  (CAD,  finite  elements,  performance,  etc.),  a  designer  can  more  readily 
achieve  the  ultimate  goal  of  an  optimal  and  high-quality  design.  Within  this  process, 
there  are  many  opportunities  to  take  advantage  of  the  true  parallel  and  distributed  nature 
of  the  PIPER  framework  because  many  design  techniques  require  numerous  independent 
design  evaluations  (which  PIPER  simply  treats  as  multiple  work  items). 

Various  PIPER  joint  venture  team  members  are  currently  beginning  to  deploy  the  PIPER 
environment  for  testing  and  validation.  In  addition,  Engineous  Software  has  established 
an  Industrial  Participants  Program  to  involve  key  industry-leading  organizations  from  the 
aerospace,  turbomachinery,  and  automotive  sectors.  Projects  stemming  from  these 
deployments  will  serve  to  provide  valuable  early  input  to  direct  the  development  and 
maturation  of  the  environment. 

At  this  point  it  is  not  certain  what  applications  can  be  disclosed  and  to  what  level  of 
detail.  As  an  alternative,  the  final  paper  will  report  on  in-house  problems  solved  with  this 
framework  as  an  example  of  the  mode  of  usage  and  the  achievable  benefits. 

IV.  Concluding  Remarks 

Due  to  the  rapid  advancement  in  technology,  more  and  more  is  expected  of  the  products 
that  companies  develop,  which  in  turn  results  in  greater  expectations  of  engineers  on  the 
tools  they  use  and  the  environment  in  which  they  design  these  products.  PIPER  is  being 
developed  to  fill  a  void  that  currently  exists  between  the  integration  needs  of  engineering 
design  organizations  and  the  capabilities  that  state-of-the-art  computer  science 
technology,  hardware,  and  the  Internet  have  to  offer.  Still  in  its  formative  stages,  the  true 
test  of  piper’s  ability  to  accommodate  those  needs  will  be  carried  out  through  the 
applications  of  the  involved  organizations  from  industry.  Early  feedback  will  provide  the 
opportunity  to  make  necessary  modifications  and  enhancements  to  allow  a  first 
commercial  release  to  be  robust  and  functionally  complete. 
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Subject:  Coupling  Status  of  Epsilon-MOEA  to  Piper 

From:  Dave  Powell,  Elon  University 
Last  Updated:  December  23,  2003 

This  work  was  funded  by  the  Navy  STTR  project  led  by  Justin  Vianese  of  Engineous 
Software.  Special  thanks  are  given  to  Oleg  Golovidov  of  Engineous  Software  for  his  help 
and  timely  support. 

In  2003,  Kalyanmoy  Deb  published  a  new  version  of  a  genetic  algorithm  for 
multiobjective  optimization.  The  code  is  called  Epsilon-MOEA  in  C++  and  in  freely 
available  from  http://www.iitk.ac.in/kangal/soft.htm  .  There  is  one  paper  describing  the 
approach,  “A  Fast  Multi-objective  Evolutionary  Algorithm  for  Finding  Well-Spread 
Pareto-Optimal  Solutions”  and  can  be  downloaded  from 
http://www.iitk.ac.in/kangal/pub.htm . 

Fiper  is  written  in  Java.  I  ported  the  Epsilon-MOEA  to  Fiper  to  insure  that  the  algorithm 
would  be  portable  and  be  able  to  be  run  on  any  platform  that  supports  fiper.  This  proved 
to  be  a  wise  decision.  By  porting  to  Java,  I  could  use  the  JBuilder  debugging  environment 
to  run  both  Fiper  and  the  Epsilon-MOEA  code. 

I  enhanced  the  original  code  to  support: 

1 .  initial  seed  of  population. 

2.  user  specifiable  output  file  with  format  defined  to  support  ggobi  and  also  to 
provide  the  actual  names  of  the  fiper  variables  and  objectives.  I  also  add  a  penalty 
value  so  the  user  can  see  if  the  archive  point  violates  constraints 

3.  user  specifiable  population  size. 

4.  penalty  is  based  on  fiper  penalty  base,  penalty  multiplier  and  penalty  exponent. 

I  validated  the  correctness  of  the  code  by  running  it  on  4  well  known  test  problems. 

I  wanted  to  display  and  analyze  the  pareto  optimal  set.  I  am  using  ggobi  which  is  freely 
downloadable  and  provides  a  scatterplot  matrix  and  a  parallel  coordinate  plots.  This 
program  will  run  with  the  xml  file  that  I  generate  to  show  values  of  variables  at  all  points 
that  the  user  clicks  on.  The  ggobi  is  freely  downloadable  from  www.ggobi.org 


Fiper  Version 

The  code  was  integrated  with  version  1.2.0  built  on  October  29,  2003. 


Installation 

1 .  Publish  epsmoga.jar  file  to  library.  It  will  then  be  one  of  the  optimization 
techniques. 


2.  Download  and  install  ggobi  from  www.ggobi.org  .  After  running  an  optimization, 
run  ggobi.  Under  file  open,  select  the  xml  file  generated  with  pareto  optimal  set 
for  analysis.  There  are  three  great  views  in  ggobi  for  analyzing  the  pareto  optimal 
set.  These  are  scatterplot,  scatterplot  matix  and  parallel  coordinates  plot.  With  all 
three  the  user  should  try  the  Identify  option.  This  option  will  show  all  of  the 
coordinate  values  for  a  particular  selected  value.  The  parallel  coordinates  plot  is 
vital  when  the  user  has  more  than  two  objectives  for  analysis. 

Test  Problems  from  Deb 

I  validated  the  port  by  running  5  constrained  test  problems  from  Deb’s  book.  The  test 
problems  are  defined  on  pages  348-370.  These  example  problems  were  implemented  as 
Calculations  and  in  some  cases  as  Excel  spreadsheets.  The  example  problems  are 
provided  in  examples.zip. 


Example 

#  of  Design  Vars 

#  of  Objectives 

#  of  Constraints 

BNH 

2 

2 

2 

OSY 

6 

2 

6 

SRN 

2 

2 

2 

TNK 

2 

2 

2 

Water 

3 

5 

7 

Tuning  Parameters 

The  main  tuning  parameters  that  the  user  needs  to  set  on  each  formulation  are  the 
mutation  rate  and  the  epsilon  for  each  objective.  The  other  settings  are  robust. 

•  Population  Size:  Default  is  100 

•  Number  of  Generations:  Default  is  1000.  This  is  a  steady  state  genetic 
algorithm  with  2  new  designs  for  each  generation.  This  will  result  in  100  + 
1000*2  =  2,100  evaluations.  Note:  Deb  typically  uses  25,000  or  50,000 
total  evaluations  in  the  test  cases  listed  above. 

•  Crossover  rate:  Default  is  1.0.  The  allowed  interval  is  .5  -  1.0. 

•  Mutation  rate:  Default  is  0.5.  The  recommended  interval  is  0  -  l/#dv 
where  #dv  is  the  number  of  design  variables. 

•  Distribution  Index  of  Crossover.  Default  is  20.  The  allowable  range  is  0.5 

-  100. 

•  Distribution  Index  of  Mutation.  Default  is  100.  The  allowable  range  is  0.5- 
500. 

•  Seed.  Default  is  .123.  The  allowable  range  is  0.0  -  1.0. 

•  Output  File  Base  Name 

•  Penalty  base.  The  default  is  10.  The  recommended  value  is  so  that 
infeasible  design  always  has  a  higher  value  then  a  feasible  design. 


•  Penalty  multiplier.  The  default  is  1.0 

•  Penalty  exponent.  The  default  is  2.0 


Coupling  Documentation  for  iSIGHT  Users 

Oleg  Golovido  and  the  entire  fiper  team  have  done  a  fantastie  job  at  allowing  3’^‘*  party 
developers  to  extend  the  optimization 

•  JBuilder  Debugging  is  fantastie.  This  allows  the  3"^^  party  developer  to  step 
through  eoupling  logic  to  see  what  is  being  returned  from  calls  to  fiper 
application  programming  interfaces. 

•  Optimization  Formulation  is  different.  In  iSight,  there  is  a  delta  for  equality 
constraints  and  a  delta  for  inequality  constraints.  Fiper  assumes  that  these  two 
quantities  are  zero  and  cannot  be  overridden  by  developer. 

•  Jar  file  needs  to  contain  the  properly  formatted  code  along  with  a  manifest 
that  is  hand  generated.  The  contents  and  format  of  the  file  can  be  easily 
determined  by  looking  at  the  fiper/lib/components/hookejeeves.jar 

Bugs 

•  Lower  and  Upper  bound  GUI  does  not  work  for  optimization  techniques  in 
vl.2  for  design  variables  (unless  one  hits  apply  after  each  entry).  This  is  also 
true  for  entering  lower  and  upper  bounds  on  constraints. 


Suggested  Enhancements  to  Fiper 

•  Delta  for  inequality  constraints  and  equality  constraints  can  not  be  specified. 
This  prevents  one  from  running  code  outside  of  fiper  on  examples  provided 
by  author  to  validate  coupling. 

•  No  ability  to  capture  log  of  coupled  organization  techniques  for  diagnostics. 
For  example,  this  gives  capability  to  get  Lagrange  multipliers  from  Grg. 

•  Need  ability  to  prematurely  stop  code  gracefully  when  you  have  achieved 
enough  gain.  Need  an  exception  that  developer  can  catch  and  handle  when 
this  happens  so  they  can  set  best  design  point. 

•  Need  a  defined  exception  thrown  when  the  simulation  code,  spreadsheet  or 
calculation  aborts. 

•  Need  a  mechanism  for  setting  a  set  of  design  points  in  the  summary  when  one 
calculates  a  pareto  optimal  solution.  Fiper  currently  considers  only  a  single 
point. 

•  Filters  need  to  be  supported  for  pareto  set  analysis.  I  am  currently  supplying  a 
ggobi  analysis  but  this  functionality  could  be  reproduced  in  fiper.  For 
example,  for  each  pareto  point,  a  weight  could  be  generated  for  each 
objective  to  show  its  relative  importance  to  the  others. 


•  On  GUI  there  is  a  Help  button.  It  is  not  clear  how  3"^^  party  developer  would 
add  help  to  it. 

•  Need  tooltips  in  xml  file  for  each  gui  attribute  that  will  display  when  mouse 
is  over  GUI  component. 

•  Need  a  file  naming  and  directory  naming  convention  for  developers  that  want 
to  write  a  file  of  data  for  subsequent  analysis  and  post  processing. 

Suggested  Enhancements  to  Epsilon  MOEA  coupling  to  fiper 

•  Modify  generateReplace  to  generate  more  than  two  designs  per  generation 
and  allow  fiper  to  evaluate  these  in  parallel. 

•  Develop  post  processing  graphics  to  simulate  ggobi. 

•  Write  out  pareto  set  every  xxx  generations  instead  of  only  at  the  end  of  the 
entire  run.  The  value  of  xxx  could  be  user  settable.  This  would  allow  the  user 
to  have  a  set  of  designs  in  case  the  user  decides  to  prematurely  abort.  Even 
better  would  be  to  support  a  stop/abort  exception  in  fiper  that  could  be  caught 
and  handled. 


Appendix  G 


Analysis  Results 


1.  DOE  Results 

Technique:  Latin  Hypercube 

Number  of 

experiments: 

Normalized  Effects  (0-100%) 


This  table  lists  the  estimated  relative  effects  that  the  various  factors  had  on  each  response: 


Sources 

HLVerDsnMax 

CLIFE 

Beam-Draft 

-2.8880309382788347 

-3.598920073340587 

SS  ENG  EXH  TEMP^2 

0.6427018558703073 

-5.237650306944958 

Beam-SS  ENG  EXH  TEMP 

0.29849550787444495 

2.351064084689636 

Wave  Height 

62.446623052754816 

-1.7072969582039548 

SS  ENG  RPM^2 

-0.7395997497099356 

-4.608648049474885 

SS  ENG  RPM 

-0.8388599155727484 

-2.0133219458620135 

SS  ENG  MASS  FL^2 

0.6776274786032248 

-0.6238238798722826 

Beam 

3.481173374043034 

11.761648162511312 

Beam''2 

2.505857107220773 

7.188900535677539 

Beam-LBP 

1.4373471945759349 

9.934920669378482 

Beam-SS  ENG  MASS  EL 

0.574500142591674 

-0.1890376680588 

SS  ENG  MASS  EL 

-0.943741623232769 

1.024160844691652 

SS  ENG  SEC 

-0.08899001191494972 

1.749882228366007 

SS  ENG  PWR  AVAIL^2 

0.38735635408047464 

4.534295508007856 

SS  ENG  EXH  TEMP 

-0.3506572880410876 

0.3063452391585458 

Draft'^2 

2.3329584859665213 

0.3028967374417246 

Beam-SS  ENG  BARE  WT 

0.2770249610679022 

5.778494219937501 

Beam-SS  ENG  ERIC  EAC 

-0.531692981533656 

-0.6784131468228056 

EBP 

-13.132199098843742 

16.274475139709647 

SS  ENG  BARE  WT 

0.0341377588280527 

-2.7915714325794143 

SS  ENG  PWR  AVAIL 

-0.7857367533016233 

-1.565128242027612 

SS  ENG  BARE  WT^2 

-0.2018551269917933 

-2.1837828013035367 

Draft 

0.3177126465104519 

-2.270190421775744 

Wave  Height^2 

0.5345829348927597 

-3.468930050426585 

SS  ENG  ERIC  FAC 

-0.7840864580946142 

-1.9286672247994543 

LBP^2 

0.26378283381960577 

3.907052936494184 

SS  ENG  SFC^2 

-0.6424253693557525 

-0.4460637743048006 

SS  ENG  ERIC  FAC^2 


1.8602429964285003 


1.5744177181384966 


All  Results  for  the  30  Runs: 

RunCounter  KG  "AUXILIARY  SYSTEMS"  "COMMAND  +  SURVEILLANCE" 

"HULL  STRUCTURE"  "FREE  SURF  COR  (DELGM) "  Draft  "FULL  LOAD  DRAFT" 
"FULL  LOAD  WT"  "ELECTRIC  PLANT"  "SS  ENG  RPM"  ARMAMENT 

Beam  "Ship  FUEL  SP  Volume"  "PROPULSION  PLANT"  "Usable 

FUEL  Weight"  "D  &  B  MARGIN"  "SS  ENG  MASS  FL"  "SS  ENG  SFC" 

GMT  "SS  ENG  EXH  TEMP"  LBP  "SS  ENG  BARE  WT"  "SS  ENG  PWR 

AVAIL"  "OUTFIT  +  FURNISHINGS"  "SS  ENG  FRIG  FAC" 

1  12.44  5195.779296875  593.654602050781  20632.39453125 

0.3  04  800003767014  8. 557  85172413  7  93  7 . 7154  6459197998  4  5744 .5  93  75 

1717.36853027344  909.310344827587  332.349578857422 

31.08338999999999  1.17889130115509  811. 886535644531 

5513.77197265625  523.403137207031  5.82584741379311 

0.19571850344828  2.86233353614807  466.8487758620687 

2  87 . 74413  7  9310344  30 . 96  6  7  044  82  75  8  64  3  556.98  9  342  9.26245117188 

0 . 98379310344828 

2  12.44  4617.6328125  553.961181640625  17995.99609375 

0.304800003767014  8. 01102413793103  8.75601387023926 

42137.8515625  1584.9765625  847.2413793103451 

332.349578857422  29.52365  1.17889130115509  1023.65191650391 

5513.77197265625  466.604064941406  5.56526637931035 

0.18531486206897  1. 9445708990097  454.6035620689653 

258.32620689655187  30.35350241379312  3584.2456206896554 

3054 . 18090820313  0 . 99 

3  12.44  5094.2490234375  590.94775390625  19429.044921875 

0.304800003767014  7.84697586206896  7.26959228515625 

44263.8203125  1592.88708496094  828.6206896551726 

332.349578857422  35.31696999999996  1.17889130115509 

826.3818359375  5513.77197265625  500.083862304688 

4.9696525862069  0. 17100985517241  6 . 97415447235107 

436.2357413793102  250. 97172413793115  31 . 78430724137934 

3611.502241379311  3389.3779296875  0.82241379310345 

4  12.44  4579.5302734375  552.413635253906  17698.326171875 

0.304800003767014  7.40951379310345  8.44564723968506 

41606.0390  62  5  1556.905  02  92  9688  958. 96  55172413  8  04 

332.349578857422  29.96928999999999  1.17889130115509 

880 .315002441406  5513.77197265625  458.228942871094 

5.11855603448276  0.19181713793103  2.2022922039032 

414 . 8066172413  7923  2  52.810344  82  758633  30. 14  910172413  795 

3638.758862068966  3039.4677734375  0. 91551724137931 

5  12.44  4826.31591796875  571.1826171875  18132.11328125 

0.304800003767014  8.44848620689655  7.78080224990845 

42423.7421875  1524.45959472656  965 . 1724137931046 

332.349578857422  34.20286999999997  1.17889130115509 

857 . 122314453125  5513.77197265625  471.106201171875 

4 . 89520086206897  0.1697094  5.44892311096191  460.726168965517 

239.94000000000003  29.33149896551726  3666.0154827586216 

3200.59375  0. 84724137931034 

6  12.44  5309.7373046875  603.590148925781  20161.9375 

0.304800003767014  8. 1750724137931  7.13365507125854 

4  54  88.6757812  5  1695 .2  5024414  063  915 . 5172413  793111 

332.349578857422  33.08876999999998  1.17889130115509 


897.0869140625  5513.77197265625  519.372863769531 

5.34191120689656  0.20352123448276  4.82242298126221 

439.29704482758603  280 .38965517241377  31 . 17110517241382 

3693.272103448277  3460.85717773438  0.97137931034483 

7  12.44  4858.86474609375  573.824829101563  19023.232421875 

0.304800003767014  7. 6282448275862  8 . 07769775390625 

43452.53515625  1557.30456542969  977.586206896553 

332.349578857422  33.53440999999997  1.17889130115509 

879.285522460938  5513.77197265625  487.307708740234 

5.26745948275862  0.17491122068966  5. 11851644515991 

445.41965172413774  247.29448275862077  29.7403003448276 

3720 . 5287241379324  3231.87182617188  0. 94655172413793 

8  12.44  4606.98583984375  554.0712890625  17765.841796875 

0.304800003767014  8.06570689655172  8.4149923324585 

41692.03515625  1564.2265625  865.8620689655177 

332.349578857422  30.63774999999999  1. 17889130115509 

850.094970703125  5513.77197265625  459.583343505859 

5.75139568965518  0. 18271395172414  2.69808077812195  399.5001 

249.13310344827596  31.37550586206899  3747.785344827588 

3050.38671875  0. 89689655172414 

9  12.44  5475.02099609375  616.286499023438  21214.369140625 

0.304800003767014  8.61253448275862  6.87179756164551 

46853.68359375  1653.31091308594  990.0  332.349578857422 

35.53979  1.17889130115509  884.800109863281  5513.77197265625 

540 . 869079589844  5.15578189655173  0.17751213103448 

6.32268381118774  457. 66486551724114  273 . 03517241379313 

27.49189275862069  3775.041965517243  3628.18017578125 

0 . 82862068965517 

10  12.44  4858.38037109375  574.694641113281  18539.29296875 

0.304800003767014  7.35483103448276  8.1856050491333  42966.34375 

1535 . 74340820313  940.3448275862079  332.349578857422 

34.42568999999997  1.17889130115509  899.530029296875 

5513.77197265625  479.651184082031  5. 04410431034483 

0 . 18661531724138  6.04006719589233  463. 78747241379284 

241.7786206896552  29.53589965517243  3802.2985862068986 
3238.20776367188  0 . 81 

11  12.44  4614.1650390625  554.0322265625  17830.580078125 

0.304800003767014  7.90165862068965  8.30792236328125 

41782.87890625  1589.53735351563  816.2068965517242 

332.349578857422  29.74647  1.17889130115509  838.37744140625 

5513.77197265625  461.013885498047  5.67694396551725 

0 . 17361076551724  2.06761908531189  402.5614034482758 

256.4875862068967  31.98870793103451  3829.555206896554 
3054.322265625  0.85344827586207 

12  12.44  4597.80322265625  552.129211425781  17885.125 

0.304800003767014  8. 12038965517241  8.23913764953613 

41814.25390625  1571.29064941406  921. 7241379310353 

332.349578857422  29.07801  1.17889130115509  867.603393554688 

5513.77197265625  461.507995605469  5.71416982758621 

0.1788125862069  1. 57782459259033  451 . 54225862068944 

260.164827586207  27.90069413793104  3856.8118275862093 

3037.9501953125  0. 89068965517241 

13  12.44  4712.35009765625  563.598205566406  18290.3203125 

0.304800003767014  7. 24546551724138  7.72704219818115 

42451 .1328125  1544 .61242675781  927.9310344827595 

332.349578857422  32.64312999999998  1.17889130115509 

889.961059570313  5513.77197265625  471.537658691406 


5.30468534482759  0.17231031034483  4.26348876953125 

472.9713827586204  243.6172413793104  30.76230379310347 
3884 . 0684482758647  3137.908203125  0.90931034482759 

14  12.44  5345.416015625  607.074768066406  20923.6171875 

0.304800003767014  8.33912068965517  7.09737300872803 

46308 . 76953125  1642 . 82470703125  841.0344827586209 

332.349578857422  34.64850999999997  1.17889130115509 

872.206604003906  5513.77197265625  532.287780761719 

4 . 93242672413793  0.19051668275862  5. 84754085540771 

488.27790000000005  271. 196551724138  28.51389620689656 

3911 . 32506896552  3544.49633789063  0 . 87206896551724 

15  12.44  5468.1865234375  616.536926269531  21787.97265625 

0.304800003767014  7.73761034482758  7.27793788909912  47480.78125 

1675.91943359375  946 . 5517241379321  332.349578857422 

35.09414999999996  1.17889130115509  903.873107910156 

5513.77197265625  550 . 744689941406  5.23023362068966 

0.20092032413793  6.88289260864258  442.3583482758619 

276 . 71241379310345  29.12709827586208  3938.5816896551755 

3636.70141601563  0. 92172413793103 

16  12.44  4910.14501953125  576.172485351563  19543.515625 

0.304800003767014  8.22975517241379  8.43145656585693 

44080.4609375  1569.86853027344  884.4827586206902 

332.349578857422  32.86594999999998  1.17889130115509 

888.273010253906  5513.77197265625  497.1962890625 

5.63971810344828  0. 18401440689655  4.46784353256226 

408.6840103448275  254. 64896551724152  27.69629344827587 

3965.838310344831  3254.4443359375  0.87827586206897 

17  12.44  5214.974609375  595.889038085938  21313.216796875 

0.304800003767014  8 .28443793103448  7.52596521377563  46547.9375 

1691.78125  822.4137931034484  332.349578857422  31.75184999999998 

1.17889130115509  906.135986328125  5513.77197265625 

536.05419921875  5 .60249224137932  0.2074226  3.53749108314514 

411.7453137931034  284.0668965517241  29.94470103448278 
3993.0949310344863  3449.04052734375  0.92793103448276 

18  12.44  5399.9912109375  611.00927734375  22395.779296875 

0.304800003767014  7.30014827586207  7.31313848495483  47990.71875 

1708.15295410156  934.1379310344837  332.349578857422 

33.31158999999997  1.17889130115509  883.443298339844 

5513.77197265625  558.775207519531  5.90029913793104 

0.18921622758621  5.17909908294678  485.2165965517238 

285 . 90551724137924  28.92269758620691  4020.3515517241417 

3592 . 72436523438  0 . 85965517241379 

19  12.44  5006.13720703125  581.804077148438  20312.916015625 

0.304800003767014  8.39380344827586  8.39269542694092 

45096.20703125  1639. 78247070313  896 . 8965517241386 

332.349578857422  31.97466999999998  1.17889130115509 

889 . 902404785156  5513.77197265625  513.192321777344 

5.19300775862069  0.17621167586207  3. 66694474220276 

427.05183103448263  267.51931034482766  32.39750931034486 

4047.608172413797  3311.62353515625  0.81620689655172 

20  12.44  5377.2392578125  606.977172851563  22064.013671875 

0.304800003767014  8. 66721724137931  7.50102376937866 

47608.015625  1726.8486328125  952.7586206896563 

332.349578857422  32.42030999999998  1.17889130115509 

888.069152832031  5513.77197265625  552.748413085938 

5 . 00687844827586  0.20482168965517  3 .69260144233704 


423.9905275862068  289.58275862068956  32.60191 

4074.8647931034525  3551.27416992188  0. 86586206896552 

21  12.44  5404.71337890625  611.077880859375  22335.115234375 

0.304800003767014  7.79229310344827  7.54861354827881  47947.25 

1690.23278808594  834.8275862068967  332.349578857422 

33.75722999999997  1.17889130115509  917.923034667969 

5513.77197265625  558.090637207031  5.86307327586208 

0.19701895862069  5.53142261505127  420.92922413793093 

282.2282758620689  28.30949551724139  4102.121413793107 
3589.25244140625  0.97758620689655 

22  12.44  4726.52392578125  562.48828125  18320.318359375 

0.304800003767014  7.46419655172414  8.70150279998779 

42541.4140625  1579.00268554688  971.3793103448288 

332.349578857422  30.19210999999999  1. 17889130115509 

903.219848632813  5513.77197265625  472.959381103516 

5.41636293103449  0.20222077931034  2. 51600575447083 

433 . 17443793103433  262.0034482758622  28.10509482758621 

4129.378034482763  3136.05615234375  0.8348275862069 

23  12.44  5593.583984375  624.278015136719  22948.875 

0.304800003767014  7.6829275862069  6.66272163391113 

48955.55859375  1741.69189453125  810.0  332.349578857422 

33.98004999999997  1.17889130115509  916.317321777344 

5513.77197265625  573 . 969482421875  5.49081465517242 

0.18011304137931  5.83670425415039  482.15529310344795 

293.26000000000005  28.71829689655174  4156. 634655172418 

3715.99658203125  0. 9651724137931 

24  12.44  4992.87744140625  579.444702148438  20388.908203125 

0.304800003767014  8. 50316896551724  8.61931896209717 

45090.5703125  1668.26867675781  872. 0689655172418 

332.349578857422  30.41492999999999  1.17889130115509 

811.966918945313  5513.77197265625  513.103515625 

5 . 78862155172415  0.20612214482759  2.51228141784668 

479.0939896551721  278.5510344827586  30.5579031034483 
4183.891275862074  3295. 15356445313  0.93413793103448 

25  12.44  5040.01708984375  585.237609863281  20451.658203125 

0.304800003767014  7.1361  7. 62921762466431  45393.1171875 

1632 . 04479980469  890 .6896551724144  332.349578857422 

31.52902999999998  1.17889130115509  973.5087890625 

5513.77197265625  517.868041992188  5. 52804051724138 

0.19311759310345  3.50541400909424  448.4809551724136 

274.8737931034483  27.08309137931035  4211.147896551729 
3351.93603515625  0. 95896551724138 

26  12.44  4823.13037109375  569.448364257813  19208.1171875 

0.304800003767014  7.57356206896552  8.16314506530762 

43633.26953125  1609.40808105469  878.275862068966 

332.349578857422  30.86056999999999  1.17889130115509 

891.911926269531  5513.77197265625  490.153930664063  4.857975 

0 . 18791577241379  2 . 91711950302124  405.6227068965517 

263.84206896551734  32.19310862068968  4238.404517241384 

3200.2509765625  0. 88448275862069 

27  12.44  4412.76318359375  540.838256835938  16932.974609375 

0.304800003767014  7.19078275862069  8.64876461029053 

40479.04296875  1500.22277832031  983.7931034482772 

332.349578857422  29.30083  1.17889130115509  880.380676269531 

5513.77197265625  440.481018066406  5.45358879310345 

0.19961986896552  1.61885702610016  417.8679206896551 

245.4558620689656  26.67429  4265.66113793104  2930.53393554688 


0 . 95275862068966 


28  12.44  4988.4150390625  581.801513671875  19752.966796875 

0.304800003767014  7.51887931034483  7.18027639389038 

44466 .19140625  1637.65747070313  853.4482758620693 

332.349578857422  32.19748999999998  1. 17889130115509 

846.799133300781  5513.77197265625  503.270751953125  5.937525 

0.18141349655172  4.03816652297974  430.1131344827585 

265.6806896551725  31.57990655172416  4292.917758620695 
3314.42919921875  0.90310344827586 

29  12.44  5261.47802734375  599.052795410156  21718.93359375 

0.304800003767014  7.95634137931034  7.44995450973511 

46979.01953125  1690.06127929688  903.1034482758628 

332.349578857422  31.30620999999999  1. 17889130115509 

842.680114746094  5513.77197265625  542.842956542969 

5 .37913706896552  0 . 19441804827586  3.34599232673645 

476 . 03268620689624  291.4213793103447  26.87869068965517 

4320.174379310351  3483.12646484375  0.84103448275862 

30  12.44  5347.71728515625  606.949462890625  20913.009765625 

0.304800003767014  8.7219  7.75766706466675  46456.7734375 

1626 .72863769531  859. 6551724137935  332.349578857422 

34.87132999999996  1.17889130115509  1046.30786132813 

5513.77197265625  534.618530273438  5 . 0813301724138 

0.1983194137931  5.69662570953369  469.91007931034454 

269.3579310344828  27.28749206896552  4347.4310000000005 
3540.59130859375  0.94034482758621 


2.  Optimization  Summary 


Optimization  technique:  "Hooke- Jeeves 
Max  Iterations 
Max  Evaluations 
Relative  Step  Size 
Step  Size  Reduction  Factor 
Termination  Step  Size 
Penalty  Base 
Penalty  Multiplier 
Penalty  Exponent 

Starting  design  point: 

SS  ENG  FRIG  FAC 
SS  ENG  RPM 
SS  ENG  MASS  FL 
SS  ENG  PWR  AVAIL 

[3500 . 0  .  .  .4500 . 0] 

SS  ENG  SFC 
SS  ENG  EXH  TEMP 
SS  ENG  BARE  WT 
LBP 

Wave  Height 

OPTIMIZATION  RUN  completed  on  Thu  Jan 


=  10 
=  100 
=  0.5 
=  0.5 
=  l.OE-6 
=  0.0 
=  1000.0 
=  2 


=  0.9  [0 . 75  ...  0 . 99] 

=  900 . 0  [800 . 0  .  .  . 999 . 0] 

=  5.39775  [4.0.  .  .6.0] 

=  3952.21 

=  0.188566  [0.1.  .  .0.3] 

=  443 . 889  [400 . 0  .  .  . 500 . 0] 

=  29.6381  [25.0.  .  .50.0] 

=  266.6  [230.0.  .  .300.0] 

=  4.0  [3 . 0  ...  5 . 0] 
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Total  design  evaluations 
Number  of  feasible  designs 

Optimum  design  point: 

SS  ENG  FRIG  FAC 
SS  ENG  RPM 
SS  ENG  MASS  FL 
SS  ENG  PWR  AVAIL 
SS  ENG  SFC 
SS  ENG  EXH  TEMP 
SS  ENG  BARE  WT 
LBP 

Wave  Height 

VRVerDspMax 

HLVerDspMax 

MaxRoll 

MaxPitch 

HLVerVelMax 

VRVerVelMax 

CLIFE 

Objective  Function 

Calculated  constraint  values  at 
VRVerDspMax  Upper  Bound 
HLVerDspMax  Upper  Bound 
MaxRoll  Upper  Bound 
MaxPitch  Upper  Bound 
HLVerVelMax  Upper  Bound 
VRVerVelMax  Upper  Bound 


=  101 
=  97 


=  0.99 
=  999.0 
=  4.0 
=  4500.0 
=  0.1 
=  400.0 
=  25.0 
=  230.0 
=  3.0 
=  1.14 
=  1.82 
=  3.8 
=  0.67 
=  1.06 
=  0.81 

=  54275.22036581 
=  1.4495044073162 

the  optimum: 

=  -0.9600000000000002 
=  -0.78 

=  -1.2999999999999998 
=  -2.33 
=  -1.04 
=  -1.29 


3.  Monte  Carlo  Summar 


% 


All  Monte  Carlo  results  are  provided  in  the  main  report. 


